[gdb/symtab] Handle struct decl with DW_AT_signature
Consider a test-case with sources 36.c:
...
struct s { int i; };
extern void f (void);
int main (void) {
struct s a;
f ();
return 0;
}
...
and 36b.c:
...
struct s { int j; };
void f (void) {
struct s b;
}
...
compiled like this:
...
$ gcc 36.c 36b.c -g
...
It contains DWARF like this:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : 36.c
<1><f4>: Abbrev Number: 2 (DW_TAG_structure_type)
<f5> DW_AT_name : s
<2><fe>: Abbrev Number: 3 (DW_TAG_member)
<ff> DW_AT_name : i
<1><110>: Abbrev Number: 5 (DW_TAG_subprogram)
<111> DW_AT_name : main
<2><12d>: Abbrev Number: 6 (DW_TAG_variable)
<12e> DW_AT_name : a
<132> DW_AT_type : <0xf4>
<0><146>: Abbrev Number: 1 (DW_TAG_compile_unit)
<14c> DW_AT_name : 36b.c
<1><168>: Abbrev Number: 2 (DW_TAG_structure_type)
<169> DW_AT_name : s
<2><172>: Abbrev Number: 3 (DW_TAG_member)
<173> DW_AT_name : j
<1><184>: Abbrev Number: 5 (DW_TAG_subprogram)
<185> DW_AT_name : f
<2><19b>: Abbrev Number: 6 (DW_TAG_variable)
<19c> DW_AT_name : b
<1a0> DW_AT_type : <0x168>
...
And when printing "struct s", we get first a random one (with int j), and then
context-specific ones (with int i in main, and int j in f):
...
$ gdb -batch a.out \
-ex "ptype struct s" \
-ex start \
-ex "ptype struct s" \
-ex "break f" -ex continue \
-ex "ptype struct s" \
| grep "int [ij];"
int j;
int i;
int j;
...
Same for -readnow.
However, if we use -fdebug-types-section:
...
$ gcc 36.c 36b.c -g -fdebug-types-section
...
we get:
...
$ gdb ... | grep "int [ij];"
int j;
int i;
int i;
$ gdb -readnow ... | grep "int [ij];"
int j;
int j;
int j;
...
This is due to the fact that both "struct s" DIEs have been moved to the
.debug_types section:
...
Compilation Unit @ offset 0x0:
Signature: 0xfd1462823bb6f7b7
<0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
<1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e> DW_AT_name : s
<2><27>: Abbrev Number: 3 (DW_TAG_member)
<28> DW_AT_name : i
Compilation Unit @ offset 0x3a:
Signature: 0x534310fbefba324d
<0><51>: Abbrev Number: 1 (DW_TAG_type_unit)
<1><57>: Abbrev Number: 2 (DW_TAG_structure_type)
<58> DW_AT_name : s
<2><61>: Abbrev Number: 3 (DW_TAG_member)
<62> DW_AT_name : j
...
and there's no longer a "struct s" DIE in the 36.c and
and 36b.c CUs to specify which "struct s" belongs in the CU. This is gcc
PR90232.
However, using a tentative patch for gcc that adds these DIEs (according to
DWARF standard: If the complete declaration of a type has been placed in a
separate type unit, an incomplete declaration of that type in the compilation
unit may provide the unique 64-bit signature of the type using a
DW_AT_signature attribute):
...
<0><d2>: Abbrev Number: 5 (DW_TAG_compile_unit)
<d8> DW_AT_name : 36.c
+ <1><f4>: Abbrev Number: 6 (DW_TAG_structure_type)
+ <f5> DW_AT_name : s
+ <f7> DW_AT_signature : signature: 0xfd1462823bb6f7b7
+ <ff> DW_AT_declaration : 1
<0><13c>: Abbrev Number: 5 (DW_TAG_compile_unit)
<142> DW_AT_name : 36b.c
+ <1><15e>: Abbrev Number: 6 (DW_TAG_structure_type)
+ <15f> DW_AT_name : s
+ <161> DW_AT_signature : signature: 0x534310fbefba324d
+ <169> DW_AT_declaration : 1
...
still does not help, because they're declarations, so new_symbol is not called
for them in process_structure_scope.
Fix this by calling new_symbol for these decls.
Build and tested on x86_64-linux.
Also tested with target board enabling by default -fdebug-types-section
-gdwarf-4, and with gcc with aforementioned tentative patch. In this
configuration, the patch reduces number of FAILs from 2888 to 238.
gdb/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (process_structure_scope): Add symbol for struct decl
with DW_AT_signature.
gdb/testsuite/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/main-foo.c: New test.
* gdb.dwarf2/struct-with-sig.exp: New file.