This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sun compiler and gdb


>>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes:

Tom> If you have a small test case, a dump of the DWARF information might
Tom> prove helpful.  If you only have a large test case, then something more
Tom> selective could help.

Tomasz> A trivial test case attached. Compiled with:
Tomasz> CC: Sun C++ 5.11 SunOS_sparc 2010/08/13

I think it is a compiler bug.  The DWARF (from your second posting)
looks like:

 <1><13b39>: Abbrev Number: 115 (DW_TAG_imported_declaration)
    <13b3a>   DW_AT_import      : <0x0>	[Abbrev Number: 0]

I don't think this is a valid DW_AT_import.

Tomasz> But still the most important question for me is: is it supposed
Tomasz> to work? I understand that there may be bugs on either side, but
Tomasz> does the general design of dwarf format/compiler/gdb allow for
Tomasz> debugging code generated with sun studio compiler using gdb?  --

Yes, it can work.  The overall design is sound.
GDB even works around compiler bugs.  This, however, can only happen
when an interested party patches GDB to do so.

In this case you could perhaps add some code to
dwarf2read.c:read_import_statement, and maybe a new variant of
follow_die_ref_or_sig, to handle this bogus DW_AT_import.

After that you'd have to try again and see what other bugs crop up.

One way to fully test the DWARF reader is to run with -readnow.
This will cause full expansion of all CUs -- so any problems will be
caught immediately at startup.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]