Consider the test-case added in this patch, with resulting dwarf:
...
Compilation Unit @ offset 0xc7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x64
Pointer Size: 8
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<d3> DW_AT_language : 2 (non-ANSI C)
<d4> DW_AT_name : imported_unit.c
<1><e4>: Abbrev Number: 3 (DW_TAG_base_type)
<e5> DW_AT_byte_size : 4
<e6> DW_AT_encoding : 5 (signed)
<e7> DW_AT_name : int
<1><eb>: Abbrev Number: 4 (DW_TAG_subprogram)
<ec> DW_AT_name : main
<f1> DW_AT_type : <0xe4>
<f5> DW_AT_external : 1
<1><f6>: Abbrev Number: 0
Compilation Unit @ offset 0xf7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x85
Pointer Size: 8
<0><102>: Abbrev Number: 2 (DW_TAG_compile_unit)
<103> DW_AT_language : 2 (non-ANSI C)
<104> DW_AT_name : <artificial>
<1><111>: Abbrev Number: 3 (DW_TAG_subprogram)
<112> DW_AT_abstract_origin: <0xeb>
<116> DW_AT_low_pc : 0x4004a7
<11e> DW_AT_high_pc : 0x4004b2
<1><126>: Abbrev Number: 0
...
When run with target board cc-with-gdb-index, we run into:
...
(gdb) break main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1 at 0x4004ab
(gdb) PASS: gdb.dwarf2/imported-unit-runto-main.exp: setting breakpoint at main
run
Starting program: /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/imported-unit-runto-main/imported-unit-runto-main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1, warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
0x00000000004004ab in main ()
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
(gdb) FAIL: gdb.dwarf2/imported-unit-runto-main.exp: running to main in runto
...
Looking at the .gdb_index section contents using objdump --dwarf=gdb_index, we
have:
...
CU table:
[ 0] 0x0 - 0x2d
[ 1] 0x2e - 0xa4
[ 2] 0xa5 - 0xc6
[ 3] 0xf7 - 0x126
[ 4] 0x127 - 0x2de
[ 5] 0x2df - 0x300
Address table:
00000000004004a7 00000000004004b2 4
Symbol table:
[489] main: 4 [global, function]
...
We see that both the main symbol, and main address range map to CU 4, which has
offset range 0x127 - 0x2de, while main actually is contained in CU 3 at offset
range 0xf7 - 0x126.
This is caused by this continue in write_gdbindex, which triggers for the PU:
...
/* CU of a shared file from 'dwz -m' may be unused by this main file.
It may be referenced from a local scope but in such case it does not
need to be present in .gdb_index. */
if (psymtab == NULL)
continue;
...
The continue causes the PU to be skipped in the CU table (we can see that the
PU offset range 0xc7-0xf6 is missing) but the references are not taking that
into account.
I've tried fixing this in the optimal way, by updating the references, but ran
into trouble when follow_die_offset tries to find the CU for the inter-CU
ref. Because the PU is missing from the CU table,
dwarf2_find_containing_comp_unit bisects to the wrong CU.
Fix this by not skipping the PU in the CU table.
Build and reg-tested on x86_64-linux, with native and target boards
cc-with-gdb-index, cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* dwarf2/index-write.c (write_gdbindex): Generate CU table entries for
CUs without psymtab.
gdb/testsuite/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* gdb.dwarf2/gdb-add-index.exp (add_gdb_index): Move ...
(ensure_gdb_index): and factor out and move ...
* lib/gdb.exp (add_gdb_index, ensure_gdb_index): ... here.
* gdb.dwarf2/imported-unit-runto-main.exp: New file.
efba5c2319