When running with target board cc-with-debug-names, I run into: ... FAIL: gdb.dwarf2/dw2-symtab-includes-lookup.exp: ptype myint (GDB internal error) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found FAIL: gdb.dwarf2/opaque-type-lookup.exp: p variable_a (GDB internal error) FAIL: gdb.dwarf2/opaque-type-lookup.exp: p variable_b (GDB internal error) FAIL: gdb.dwarf2/varval.exp: print bad_die_val1 (GDB internal error) ... Command-line reproducer of first fail: ... $ gdb -q -batch ./outputs/gdb.dwarf2/dw2-symtab-includes-lookup/dw2-symtab-includes-lookup -ex "ptype myint" /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.h:298: internal-error: length: Assertion `m_length != 0' failed. ... We're trying to find (in dwarf2_find_containing_comp_unit) the containing CU for DIE 0xa5: ... Compilation Unit @ offset 0x9a: Length: 0x16 (32-bit) Version: 4 Abbrev Offset: 0x5a Pointer Size: 8 <0><a5>: Abbrev Number: 2 (DW_TAG_partial_unit) <a6> DW_AT_stmt_list : 0xe8 <1><aa>: Abbrev Number: 3 (DW_TAG_base_type) <ab> DW_AT_byte_size : 4 <ac> DW_AT_encoding : 5 (signed) <ad> DW_AT_name : myint <1><b3>: Abbrev Number: 0 ... which is 0x9a, but when getting the length of the unit, it turns out to be 0. This is a regression since commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), which starting keeping length at 0 when reading the CU list from .debug_names, and relied on a later set_length to fill in the actual length. This happens fine for CUs, but in this case it's a PU.
Backtrace at assert: ... (gdb) bt #0 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff4a05375 in __GI_abort () at abort.c:79 #2 0x0000000000c81e49 in dump_core () at /home/vries/gdb_versions/devel/src/gdb/utils.c:202 #3 0x0000000000c8247f in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) ( problem=0x2785c60 <internal_error_problem>, file=0x14cf880 "/home/vries/gdb_versions/devel/src/gdb/dwarf2/read.h", line=298, fmt=0x14cf850 "%s: Assertion `%s' failed.", ap=0x7fffffff90e8) at /home/vries/gdb_versions/devel/src/gdb/utils.c:450 #4 0x0000000000c82555 in internal_verror ( file=0x14cf880 "/home/vries/gdb_versions/devel/src/gdb/dwarf2/read.h", line=298, fmt=0x14cf850 "%s: Assertion `%s' failed.", ap=0x7fffffff90e8) at /home/vries/gdb_versions/devel/src/gdb/utils.c:476 #5 0x00000000013cef2f in internal_error ( file=0x14cf880 "/home/vries/gdb_versions/devel/src/gdb/dwarf2/read.h", line=298, fmt=0x14cf850 "%s: Assertion `%s' failed.") at /home/vries/gdb_versions/devel/src/gdbsupport/errors.cc:58 #6 0x00000000006b1b37 in dwarf2_per_cu_data::length (this=0x369e3a0) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.h:298 #7 0x00000000007121d2 in dwarf2_find_containing_comp_unit ( sect_off=(unknown: 0xa5), offset_in_dwz=0, all_comp_units=std::vector of length 9, capacity 9 = {...}) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:23558 #8 0x0000000000712280 in dwarf2_find_containing_comp_unit ( sect_off=(unknown: 0xa5), offset_in_dwz=0, per_bfd=0x369cf80) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:23576 #9 0x00000000006ec16b in process_imported_unit_die (die=0x36bdc50, cu=0x2d26d00) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:8577 #10 0x00000000006ec6c8 in process_die (die=0x36bdc50, cu=0x2d26d00) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:8735 #11 0x00000000006ee4f4 in read_file_scope (die=0x36bdb50, cu=0x2d26d00) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:9642 #12 0x00000000006ec448 in process_die (die=0x36bdb50, cu=0x2d26d00) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:8643 #13 0x00000000006ebbcc in process_full_comp_unit (cu=0x2d26d00, pretend_language=language_minimal) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:8412 #14 0x00000000006e91f6 in process_queue (per_objfile=0x2d28540) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:7658 #15 0x00000000006db090 in dw2_do_instantiate_symtab (per_cu=0x369e420, per_objfile=0x2d28540, skip_partial=false) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:2063 #16 0x00000000006db139 in dw2_instantiate_symtab (per_cu=0x369e420, per_objfile=0x2d28540, skip_partial=false) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:2085 ...
Created attachment 14335 [details] Demonstrator patch This is an alternative way of fixing PR29453. Basically, we look into the CU header to find the length.
(In reply to Tom de Vries from comment #2) > Created attachment 14335 [details] > Demonstrator patch > > This is an alternative way of fixing PR29453. > > Basically, we look into the CU header to find the length. The more intrusive, but more maintainable version of this would be to just always call create_all_comp_units, not just for readnow and cooked index, but also for .debug_names and .gdb_index. Tom, I think you suggested that already somewhere.
(In reply to Tom de Vries from comment #3) > (In reply to Tom de Vries from comment #2) > > Created attachment 14335 [details] > > Demonstrator patch > > > > This is an alternative way of fixing PR29453. > > > > Basically, we look into the CU header to find the length. > > The more intrusive, but more maintainable version of this would be to just > always call create_all_comp_units, not just for readnow and cooked index, > but also for .debug_names and .gdb_index. > > Tom, I think you suggested that already somewhere. Hmm, this also provides us with an opportunity to fix PR25969.
Created attachment 14336 [details] Tentative patch Currently testing
(In reply to Tom de Vries from comment #5) > Created attachment 14336 [details] > Tentative patch > > Currently testing Hmm, I guess I'll need to give create_signatured_type_table_from_debug_names the same treatment as create_cus_from_debug_names, that is, transform it into check_signatured_type_table_from_debug_names.
(In reply to Tom de Vries from comment #5) > Created attachment 14336 [details] > Tentative patch > > Currently testing Testing went fine (native + target board cc-with-debug-names), so I suppose it's just a question of adding the TU handling bit.
Fix was submitted here: https://sourceware.org/pipermail/gdb-patches/2022-September/192031.html
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=107ab8d45df84b442ce2d79c6dda3a9b3afc80d5 commit 107ab8d45df84b442ce2d79c6dda3a9b3afc80d5 Author: Tom de Vries <tdevries@suse.de> Date: Thu Aug 10 15:46:30 2023 +0200 [gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.exp I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board cc-with-debug-names, and ran into: ... FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found ... The first FAIL is a known issue, PR symtab/29572. The following FAIL is a consequence of the first FAIL, so require for the second test that the first test passes. Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b17ef9dcd8d16eedf4e60565cd7701698b5a0b6b commit b17ef9dcd8d16eedf4e60565cd7701698b5a0b6b Author: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> Date: Wed Dec 6 10:29:17 2023 +0100 [gdb/symtab] Redo "Fix assert in set_length" This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due to a regression reported in PR29572, and implements a different fix for PR29453. The fix is to not use the CU table in a .debug_names section to construct all_units, but instead use create_all_units, and then verify the CU table from .debug_names. This also fixes PR25969, so remove the KFAIL. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969
Fixed.