Seems iconv library in macos >= 14.4 has some changes that appeared to
be breaking in case converting from "wchar_t" encoding.
As macos libiconv supports "UTF-32LE", GDB will use this encoding
instead.
The problem appears when break in nested noreturn calls.
panic_abort() and esp_system_abort() are noreturn functions:
#0 0x4008779f in panic_abort ()
#1 0x40087a78 in esp_system_abort ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Assembly listing:
40081ad4 <panic_abort>:
40081ad4: 004136 entry a1, 32
40081aeb: ffff06 j 40081aeb <panic_abort+0x17>
...
40085614 <esp_system_abort>:
40085614: 004136 entry a1, 32
40085619: fc4ba5 call8 40081ad4 <panic_abort>
4008561c <__ubsan_include>:
4008561c: 004136 entry a1, 32
PC register for frame esp_system_abort points to the next instruction after
instruction with address 40085619.
It is ENTRY instruction for __ubsan_include. This caused wrong unwinding
because we are not in __ubsan_include at this frame. In general for
noreturn functions there should be RET instruction. This is why it works
in all other cases.
PC register can point to entry instruction only for the innermost frame.
It is not possible otherwise.
The fix is making it not possible to go with not innermost frame into
the code block which collects frame cache for frames when PC is on entry
instruction.
xtensa_pseudo_register_read/write implement access to a0-a15 registers
in the case of Window ABI. However the split between 'raw' and
'pseudo' registers was made based on the location of the first masked
register. To make access to a0-a15 go through the pseudo register
mechanism, the split should be set based on the location of a0,
instead.
When parsing a core file on hardware configurations without the
zero-overhead loop option (e.g. ESP32-S2 chip), GDB used to assert
while trying to call 'raw_supply' for lbeg, lend, lcount registers,
even though they were not set. This was because regnum == -1 was used
to indicate "supply all registers" and lbeg_regnum == -1 was used to
indicate "lbeg register not present", and regnum == lbeg_regnum check
was considered successful.
Add support to core dump files generated by ESP32C3 boards.
GDB is now aware on how to parse the core dump regs structure.
Port from: esp-binutils-develop
ar_base is uninitialized for cores w/o windowed registers as their
regmap doesn't have register 0x0100.
Check that ar_base is initialized and if not initialize it with a0_base.
gdb/
* xtensa-tdep.c (xtensa_derive_tdep): Make sure ar_base is
initialized.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
If you try to call Frame.static_link for a frame without debug info,
gdb crashes:
```
Temporary breakpoint 1, 0x000000013f821650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
The problem was a missing check if get_frame_block returns nullptr
inside frame_follow_static_link.
With this, it works:
```
Temporary breakpoint 1, 0x000000013f941650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
None
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366
Approved-By: Tom Tromey <tom@tromey.com>
On arm-linux the linaro CI occasionally reports:
...
(gdb) up 10
#4 0x0001b864 in pthread_join ()
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10
...
while this is expected:
...
(gdb) up 10
#3 0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
76 pthread_join (thread, NULL);
(gdb) PASS: gdb.threads/staticthreads.exp: up 10
...
Thiago investigated the problem, and using valgrind found an invalid read in
arm_exidx_fill_cache.
The problem happens as follows:
- an objfile and corresponding per_bfd are allocated
- some memory is allocated in arm_exidx_new_objfile using
objfile->objfile_obstack, for the "exception table entry cache".
- a symbol reread is triggered, and the objfile, including the
objfile_obstack, is destroyed
- a new objfile is allocated, using the same per_bfd
- again arm_exidx_new_objfile is called, but since the same per_bfd is used,
it doesn't allocate any new memory for the "exception table entry cache".
- the "exception table entry cache" is accessed by arm_exidx_fill_cache,
and we have a use-after-free.
This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling
information per-bfd instead of per-objfile"), which changed the "exception
table entry cache" from per-objfile to per-bfd, but failed to update the
obstack_alloc.
Fix this by using objfile->per_bfd->storage_obstack instead of
objfile->objfile_obstack.
I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
fixes it.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31254
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254
