With target board, we run into a FAIL because we expect a length of 2 here, but get 5: ... (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M 5^M (gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr'))) ... In more detail, we get: ... (gdb) python print (gdb.lookup_static_symbols ('rr')[0].value ()) 99 (gdb) python print (gdb.lookup_static_symbols ('rr')[1].value ()) 42 (gdb) python print (gdb.lookup_static_symbols ('rr')[2].value ()) 42 (gdb) python print (gdb.lookup_static_symbols ('rr')[3].value ()) 42 (gdb) python print (gdb.lookup_static_symbols ('rr')[4].value ()) 42 ... The interesting bit is that the rr DWARF records are actually not moved into a partial unit. Only the type is moved into the alt file: ... <1><100>: Abbrev Number: 11 (DW_TAG_variable) <101> DW_AT_name : rr <104> DW_AT_decl_file : 1 <105> DW_AT_decl_line : 46 <106> DW_AT_type : <alt 0xc5> <10a> DW_AT_location : 9 byte block: 3 2c 10 60 0 0 0 0 0 (DW_OP_addr: 60102c) <1><20f>: Abbrev Number: 11 (DW_TAG_variable) <210> DW_AT_name : rr <213> DW_AT_decl_file : 1 <214> DW_AT_decl_line : 18 <215> DW_AT_type : <alt 0xc5> <219> DW_AT_location : 9 byte block: 3 30 10 60 0 0 0 0 0 (DW_OP_addr: 601030) ...
This fixes it: ... diff --git a/gdb/block.c b/gdb/block.c index b49c548adc8..899ec053692 100644 --- a/gdb/block.c +++ b/gdb/block.c @@ -484,10 +484,12 @@ initialize_block_iterator (const struct block *block, return; } +#if 0 /* If this is an included symtab, find the canonical includer and use it instead. */ while (cu->user != NULL) cu = cu->user; +#endif /* Putting this check here simplifies the logic of the iterator functions. If there are no included symtabs, we only need to ... Regression testing (not using cc-with-dwz-m) on x86_64 gets us one extra failure, in an artifical test-case: ... FAIL: gdb.dwarf2/dwz.exp: p the_int ... Looking at the test-case itself, I don't see how this code could occur in reality. Still, it's not bad for gdb to handle this correctly, but I suspect the current fix is also effective for cases where we don't want that.
(In reply to Tom de Vries from comment #1) > This fixes it: > ... > diff --git a/gdb/block.c b/gdb/block.c > index b49c548adc8..899ec053692 100644 > --- a/gdb/block.c > +++ b/gdb/block.c > @@ -484,10 +484,12 @@ initialize_block_iterator (const struct block *block, > return; > } > > +#if 0 > /* If this is an included symtab, find the canonical includer and > use it instead. */ > while (cu->user != NULL) > cu = cu->user; > +#endif > > /* Putting this check here simplifies the logic of the iterator > functions. If there are no included symtabs, we only need to > ... > > Regression testing (not using cc-with-dwz-m) on x86_64 gets us one extra > failure, in an artifical test-case: > ... > FAIL: gdb.dwarf2/dwz.exp: p the_int > ... > Looking at the test-case itself, I don't see how this code could occur in > reality. Still, it's not bad for gdb to handle this correctly, but I suspect > the current fix is also effective for cases where we don't want that. I've also tested this patch with target boards cc-with-dwz and cc-dwz-m, and no regressions other than the one for gdb.dwarf2/dwz.exp.
https://sourceware.org/pipermail/gdb-patches/2023-August/201905.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=e061219f5d600af5b33418553f192e0cb9fc9ca9 commit e061219f5d600af5b33418553f192e0cb9fc9ca9 Author: Tom de Vries <tdevries@suse.de> Date: Wed Sep 6 11:00:01 2023 +0200 [gdb/symtab] Fix too many symbols in gdbpy_lookup_static_symbols When running test-case gdb.python/py-symbol.exp with target board cc-with-dwz-m, we run into: ... (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M 4^M (gdb) FAIL: gdb.python/py-symbol.exp: \ print (len (gdb.lookup_static_symbols ('rr'))) ... while with target board unix we have instead: ... (gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M 2^M (gdb) PASS: gdb.python/py-symbol.exp: \ print (len (gdb.lookup_static_symbols ('rr'))) ... The problem is that the loop in gdbpy_lookup_static_symbols loops over compunits representing both CUs and PUs: ... for (compunit_symtab *cust : objfile->compunits ()) ... When doing a lookup on a PU, the user link is followed until we end up at a CU, and the lookup is done in that CU. In other words, when doing a lookup in the loop for a PU we duplicate the lookup for a CU that is already handled by the loop. Fix this by skipping PUs in the loop in gdb.lookup_static_symbols. Tested on x86_64-linux. PR symtab/25261 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25261
Fixed.