This commit restores gdb functionality of stepping and backtrace commands.
From the machine code perspective, it could be additional data between
two functions, such as alignment or literal pool. But computing the position
of the previous function's last instruction is not achievable without
debugging information.
This commit fixes an issue that the backtrace will be interrupted on a
frame where a noreturn function is called. This issue doesn't occur
for every call to noreturn functions, but only for calls such that:
- the call is the last instruction of the caller function
- the next function starts immediately after this call instruction;
in most cases this means that the caller function size is divisible
by 4 bytes, so no padding is added between the last instruction and
the next function.
For example, the following generated code will exhibit this issue:
esp_system_abort:
entry a1, 32
movi.n a10, a2
call8 panic_abort
some_other_function:
entry a1, 32
...
In this case, esp_system_abort function is 3 + 2 + 3 = 8 bytes long,
so no padding is required before "some_other_function". When the call
to panic_abort happens, the return address is set to the next
instruction, i.e. the "entry" instruction of "some_other_function".
The observed behavior is that the backtrace is interrupted:
#0 panic_abort (details=0x3ffb5c3b "abort() was called at PC 0x400d485f on core 0")
at $IDF_PATH/components/esp_system/panic.c:389
#1 0x40084fb0 in esp_system_abort (
details=0x3ffb5c3b "abort() was called at PC 0x400d485f on core 0")
at $IDF_PATH/components/esp_system/esp_system.c:129
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The reason is that when the unwinder inspects the instruction at the
return address in the caller frame, the instruction is an ENTRY,
which is part of the next function. Previously it was considered that
the only case when this can happen is if the frame is the outermost
frame and the entry instruction hasn't executed yet.
This commit fixes that assumption, by checking additionally if the
instruction preceding ENTRY is a call. If it is, the frame is handled
as usual.
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>
When running the gdb testsuite with gnatmake-4.8, I get many fails of the
following form:
...
gcc: error: unrecognized command line option '-fgnat-encodings=all'^M
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M
compiler exited with status 1
compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb
gcc: error: unrecognized command line option '-fgnat-encodings=all'
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error
FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb
...
Fix this by marking the test unsupported instead, such that we have:
...
UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \
(unsupported option '-fgnat-encodings=all')
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-09-10 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_compile_test): Handle unrecognized command line
option.
I forgot to 'git commit' the ChangeLog for the previous patch.
2021-09-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (dwarf2_per_objfile::resize_symtabs): Remove.
* dwarf2/read.c (all_comp_units_iterator, all_comp_units_range):
New classes.
(dwarf2_per_objfile::symtab_set_p)
(dwarf2_per_objfile::get_symtab, dwarf2_per_objfile::set_symtab):
Adjust to resizeable vectors.
(dwarf2_gdb_index::expand_symtabs_matching)
(dwarf2_base_index_functions::map_symbol_filenames)
(dwarf2_debug_names_index::expand_symtabs_matching): Use
all_comp_units_range.
(dwarf2_initialize_objfile, dwarf2_build_psymtabs)
(add_type_unit): Don't call resize_symtabs.
On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into:
...
(gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile
First line of eu-unstrip: \
0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe]
FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id
...
The test expects an actual file name instead of '[exe]', but that only got
introduced with eu-unstrip 0.161. Before it printed '[exe]' or '[pie]'.
Fix this by updating the regexp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-09-09 Tom de Vries <tdevries@suse.de>
* gdb.base/coredump-filter-build-id.exp: Handle older eu-unstrip.
I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8:
...
FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \
(unexpected output)
...
due to function f2 instead of f3 being listed.
AFAICT, this is caused by a difference in debug info:
...
$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
| egrep "DW_AT_name.*: f[1-3]"
<72> DW_AT_name : f1
<a1> DW_AT_name : f2
<d0> DW_AT_name : f3
...
vs:
...
$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
| egrep "DW_AT_name.*: f[1-3]"
<f4> DW_AT_name : f3
<123> DW_AT_name : f2
<152> DW_AT_name : f1
...
and the command documentation does not mention an imposed order, so fix this
by allowing f2 as well.
Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re
variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern
overall.
Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix
by updating the regexp.
Then I ran with clang and found another FAIL, fix by updating the regexp.
Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and
clang-12.0.1.
gdb/testsuite/ChangeLog:
2021-09-09 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info.exp: Fix regexps. Add missing message argument
to mi_gdb_test. Factor out regexps for functions and variables.
PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test
suite when using the "fission" target board. They are both caused by
the patches that merge the list of CUs with the list of TUs (and to a
lesser degree by the patches to share DWARF data across objfiles), and
the underlying issue is the same: it turns out that reading a DWO can
cause new type units to be created. This means that the list of
dwarf2_per_cu_data objects depends on precisely which CUs have been
expanded. However, because the type units can be created while
expanding a CU means that the vector of CUs can expand while it is
being iterated over -- a classic mistake. Also, because a TU can be
added later, it means the resize_symtabs approach is incorrect.
This patch fixes resize_symtabs by removing it, and having set_symtab
resize the vector on demand. It fixes the iteration problem by
introducing a safe (index-based) iterator and changing the relevant
spots to use it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893
(cherry picked from commit d58e54bd277b90d847be09ae4b18bfdbc0dc2066)
The handler for 'info proc status' for native processes on FreeBSD
uses the 'j' size modifier along with uintmax_t / intmax_t casts to
output integer values for types such as off_t that are not aliases of
a basic C type such as 'int' or 'long'. printf_filtered does not
support the 'j' modifer, so this resulted in runtime errors in
practice:
(gdb) info proc stat
process 8674
Name: ls
State: T (stopped)
Parent process: 8673
Process group: 8674
Session id: 2779
Unrecognized format specifier 'j' in printf
Instead, use plongest and pulongest to generate the output strings of
these integer values.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_nat_target::info_proc): Use plongest and
pulongest instead of %j.
On a machine on Open Build Service I'm running into a SIGILL for test-case
gdb.arch/amd64-disp-step-avx.exp:
...
Program received signal SIGILL, Illegal instruction.^M
test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
40 vmovsd ro_var(%rip),%xmm0^M
(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
continue to test_rip_vex2_end
...
The SIGILL happens when trying to execute the first avx instruction in the
executable.
I can't directly access the machine, but looking at the log for test-case
gdb.arch/i386-avx.exp, it seems that there's no avx support:
...
Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
68 if (have_avx ())^M
(gdb) print have_avx ()^M
$1 = 0^M
...
Fix this by:
- adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
function from gdb.arch/i386-avx.c
- using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
and gdb/testsuite/gdb.arch/i386-avx.exp.
Tested on my x86_64-linux laptop with avx support, where both test-cases pass.
gdb/testsuite/ChangeLog:
2021-09-04 Tom de Vries <tdevries@suse.de>
PR testsuite/26950
* gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
(have_avx): Move ...
* gdb/testsuite/lib/gdb.exp (have_avx): ... here. New proc.
* gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
* gdb/testsuite/gdb.arch/i386-avx.exp: Same.
When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
(gdb) call clear_complaints()^M
No symbol "clear_complaints" in current context.^M
(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
...
The problem is that lto has optimized away clear_complaints, and consequently
the selftests cannot run.
Fix this by:
- using info function to detect presence of clear_complaints
- handling the absence of clear_complaints by calling untested
...
(gdb) UNTESTED: gdb.gdb/complaints.exp: \
Cannot find clear_complaints, skipping test
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-09-03 Tom de Vries <tdevries@suse.de>
* gdb.gdb/complaints.exp: Use untested if clear_complaints cannot
be found.
When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
(got interactive prompt)
FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
...
and similar in gdb.gdb/selftest.exp.
The first FAIL in more detail:
...
(gdb) break captured_main^M
Function "captured_main" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
(got interactive prompt)
...
The problem is that lto has optimized away the captured_main function
and consequently the selftests dependent on that cannot run.
Fix this by:
- using gdb_breakpoint to detect failure to set the breakpoint
- handling the failure to set a breakpoint by calling untested
- not emitting the warning if we've already got untested
such that we have:
...
(gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \
captured_main, skipping testcase.
...
gdb/testsuite/ChangeLog:
2021-09-03 Tom de Vries <tdevries@suse.de>
* lib/selftest-support.exp: Emit untested when not being able to set
breakpoint.
