bornintelligent / google-breakpad

Automatically exported from code.google.com/p/google-breakpad
0 stars 0 forks source link

DWARF dumper doesn't handle DW_AT_specification #283

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The DWARF symbol dumper doesn't handle the DW_AT_specification attribute.
This attribute can be used to refer to another DIE to provide attributes
like the name, etc. The result is that many functions wind up without a
name attribute, and thus don't appear in the output. A simple test:

testspec.cc
----------------
struct frotzy { int foo (int a, int b); };

int frotzy::foo (int a, int b) { return a+b; }

int
main (int argc, char **argv)
{
  frotzy a;

  return a.foo(-1, 1);
}
----------------

g++ -gdwarf-2 -o testspec.o -c testspec.cc
g++ -gdwarf-2 -o testspec testspec.o
dsymutil testspec
dwarfdump testspec.dSYM/

excerpted output:

...
0x00000031:         TAG_subprogram [3] *
                     AT_external( 0x01 )
                     AT_name( "foo" )
                     AT_decl_file( 0x01 )
                     AT_decl_line( 0x01 )
                     AT_MIPS_linkage_name( "_ZN6frotzy3fooEii" )
                     AT_type( {0x00000054} ( int ) )
                     AT_declaration( 0x01 )
...
0x00000061:     TAG_subprogram [8] *
                 AT_specification( {0x00000031} ( foo ) )
                 AT_decl_line( 0x03 )
                 AT_low_pc( 0x00001fce )
                 AT_high_pc( 0x00001fdc )
                 AT_frame_base( <0x1> 55  ( reg5  ) )
                 AT_sibling( {0x0000009b} )

Note that the first TAG_subprogram for 'foo' is essentially just a
prototype, and the second is the actual definition. The second uses
DW_AT_specification to refer back to the first, and doesn't have its own
DW_AT_name.

dump_syms output looks like:
MODULE mac x86 08477EE3634ED44806CE2F1ADB4007190 testspec
FILE 1 testspec.cc
FUNC fdc 23 0 main
fdc 6 6 1
fe2 1b 10 1
ffd 2 11 1
fff 1001 11 1

Note the complete lack of a frotzy::foo entry.

I'm going to take a pass at fixing this.

Original issue reported on code.google.com by ted.mielczarek on 2 Dec 2008 at 12:00

GoogleCodeExporter commented 9 years ago
This is not hard to fix as long as we make the assumption that any DIEs 
referenced in
this manner will already have been seen. In practice, this seems to be the case,
although the spec does not require it. I think this is probably good enough, 
although
I have yet to test it on actual Mozilla binaries.

Original comment by ted.mielczarek on 3 Dec 2008 at 8:32

Attachments:

GoogleCodeExporter commented 9 years ago
This patch works on Mozilla binaries. My previous patch only worked on trivial
(single compile unit) input. DW_AT_specification can be DW_FORM_ref4, which is a
compilation unit-relative offset, so the offset needs to be made absolute in 
order to
look it up in the offset_to_funcinfo_ map.

Original comment by ted.mielczarek on 4 Dec 2008 at 4:35

Attachments:

GoogleCodeExporter commented 9 years ago
Fixed in r303.

Original comment by ted.mielczarek on 8 Dec 2008 at 1:14