]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/ChangeLog
[gdb/symtab] Handle struct decl with DW_AT_signature
authorTom de Vries <tdevries@suse.de>
Tue, 28 Apr 2020 04:12:35 +0000 (06:12 +0200)
committerTom de Vries <tdevries@suse.de>
Tue, 28 Apr 2020 04:12:35 +0000 (06:12 +0200)
commit15cd93d05e8e84644acc8bbeaa3d5f4280cc5159
tree400712532427c91f20a7757055e25f3a6e420819
parent30b57e1bea5b4bb2b0430e444db3848694d342b3
[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.
gdb/ChangeLog
gdb/dwarf2/read.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.dwarf2/main-foo.c [new file with mode: 0644]
gdb/testsuite/gdb.dwarf2/struct-with-sig.exp [new file with mode: 0644]