sun compiler and gdb

sun compiler and gdb

[Tomasz Grobelny]

Hi all,
Should it be possible to debug C++ programs compiled using sun compiler
using GDB? If so which debug format should I use? Which versions of the
compiler/gdb support such a scenario? Currently the situation looks like
this (which does not look very promising):

> /opt/solstudio12.2/bin/CC -V
CC: Sun C++ 5.11 SunOS_i386 2010/08/13
usage: CC [ options ] files.  Use 'CC -flags' for details
> /opt/solstudio12.2/bin/CC -g -xdebugformat=dwarf test.cpp
> gdb -q ./a.out
Reading symbols from /full/path/to/my/a.out...done.
(gdb) break fun
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in
module /full/path/to/my/a.out]
(gdb) break main
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in
module /full/path/to/my/a.out]
(gdb) run
Starting program: /full/path/to/my/a.out
[Thread debugging using libthread_db enabled]
hello world
[Inferior 1 (process 9412    ) exited normally]
(gdb) quit
> uname -a
SunOS solac1 5.10 Generic_137138-09 i86pc i386 i86pc
> 

gdb version is 7.4.1
Any ideas what is wrong here?
-- 
Regards,
Tomasz Grobelny

Re: sun compiler and gdb

[Sergio Durigan Junior]

On Thursday, May 03 2012, Tomasz Grobelny wrote:

> Hi all,
> Should it be possible to debug C++ programs compiled using sun compiler
> using GDB? If so which debug format should I use? Which versions of the
> compiler/gdb support such a scenario? Currently the situation looks like
> this (which does not look very promising):

Indeed.  In a quick search using Google, I found some links reporting
that the compiler is kind of broken, probably when it comes to DWARF
generation.  Anyway, by reading this link:

    http://netbeans.org/bugzilla/show_bug.cgi?id=89876

especifically in comment #8, I saw that you can try enabling some
options in your C++ compiler:

    -Qoption cg -h_gcc -xO0 -g

Also, I saw that passing `-xs' to the compiler might help a bit.  But
overall, AFAIU, you don't have many options here, unfortunately.
However, I'm definitely not an expert in the platform, so maybe someone
more experienced will show up and help you further.

Good luck.

-- 
Sergio

Re: sun compiler and gdb

[Tomasz Grobelny]

On Thu, 03 May 2012 03:49:41 -0300, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> On Thursday, May 03 2012, Tomasz Grobelny wrote:
> 
>> Hi all,
>> Should it be possible to debug C++ programs compiled using sun compiler
>> using GDB? If so which debug format should I use? Which versions of the
>> compiler/gdb support such a scenario? Currently the situation looks
like
>> this (which does not look very promising):
> 
> Indeed.  In a quick search using Google, I found some links reporting
> that the compiler is kind of broken, probably when it comes to DWARF
> generation.  Anyway, by reading this link:
> 
>     http://netbeans.org/bugzilla/show_bug.cgi?id=89876
> 
> especifically in comment #8, I saw that you can try enabling some
> options in your C++ compiler:
> 
>     -Qoption cg -h_gcc -xO0 -g
> 
> Also, I saw that passing `-xs' to the compiler might help a bit.  But
> overall, AFAIU, you don't have many options here, unfortunately.
> However, I'm definitely not an expert in the platform, so maybe someone
> more experienced will show up and help you further.
> 
> Good luck.
> 

Now it looks like this (on sparc as the comment suggested that):
> /opt/solstudio12.2/prod/bin/CC -xdebugformat=dwarf -Qoption cg -h_gcc
-xO0 -g -xs test.cpp
> gdb -q ./a.out
Reading symbols from /login/sg209371/a.out...done.
(gdb) break main
Die: DW_TAG_<unknown> (abbrev 8, offset 0x199)
  parent at offset: 0x175
  has children: TRUE
  attributes:
    DW_AT_name (DW_FORM_string) string: "basic_ostream" (is canonicalized)
    DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"
(not canonicalized)
    DW_AT_decl_file (DW_FORM_data1) constant: 2
    DW_AT_decl_line (DW_FORM_data1) constant: 74
Dwarf Error: Cannot find type of die [in module /login/sg209371/a.out]
(gdb) run
Starting program: /login/sg209371/a.out
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
hello world

Program exited normally.
(gdb) quit
>

This time this is gdb 7.0.1.
The question is indeed whether the issue is on compiler side or gdb side.
The comments from the link you mentioned are from 2007, I would think that
Oracle is capable of fixing a bug in 5 years...
Also the dwarfdump shows some sensible information (some symbols, names of
the source files).
-- 
Regards,
Tomasz Grobelny

Re: sun compiler and gdb

[Tom Tromey]

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

tomasz> Die: DW_TAG_<unknown> (abbrev 8, offset 0x199)
[...]
Tomasz> Dwarf Error: Cannot find type of die [in module /login/sg209371/a.out]

Tomasz> This time this is gdb 7.0.1.

Tomasz> The question is indeed whether the issue is on compiler side or
Tomasz> gdb side.  The comments from the link you mentioned are from
Tomasz> 2007, I would think that Oracle is capable of fixing a bug in 5
Tomasz> years...  Also the dwarfdump shows some sensible information
Tomasz> (some symbols, names of the source files).

This kind of question can't be answered without more information.

It could be a compiler bug, or a gdb bug, or a disagreement about the
interpretation of DWARF.

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

For example, in the above you could examine the DWARF for DIE 0x199.
gdb just says DW_TAG_<unknown>, which isn't very helpful... but
presumably the platform DWARF dumper would do better.

Tom

Re: sun compiler and gdb

[Tomasz Grobelny]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

On Wed, 09 May 2012 14:30:52 -0600, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net>
writes:
> 
> tomasz> Die: DW_TAG_<unknown> (abbrev 8, offset 0x199)
> [...]
> Tomasz> Dwarf Error: Cannot find type of die [in module
> /login/sg209371/a.out]
> 
> Tomasz> This time this is gdb 7.0.1.
> 
> Tomasz> The question is indeed whether the issue is on compiler side or
> Tomasz> gdb side.  The comments from the link you mentioned are from
> Tomasz> 2007, I would think that Oracle is capable of fixing a bug in 5
> Tomasz> years...  Also the dwarfdump shows some sensible information
> Tomasz> (some symbols, names of the source files).
> 
> This kind of question can't be answered without more information.
> 
I will be happy to provide it (but only for the next two weeks as I will
lose access to those solaris machines later).

> It could be a compiler bug, or a gdb bug, or a disagreement about the
> interpretation of DWARF.
> 
I cannot tell...

> If you have a small test case, a dump of the DWARF information might
> prove helpful.  If you only have a large test case, then something more
> selective could help.
> 
A trivial test case attached. Compiled with:
CC: Sun C++ 5.11 SunOS_sparc 2010/08/13

> For example, in the above you could examine the DWARF for DIE 0x199.
> gdb just says DW_TAG_<unknown>, which isn't very helpful... but
> presumably the platform DWARF dumper would do better.
> 
I used dwarfdump from the same directory as the compiler.

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

[-- Attachment #2: gdbtest.7z --]
[-- Type: application/octet-stream, Size: 69557 bytes --]

Re: sun compiler and gdb

[Tomasz Grobelny]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Thu, 10 May 2012 00:57:56 +0200, Tomasz Grobelny
<tomasz@grobelny.oswiecenia.net> wrote:
> A trivial test case attached. Compiled with:
> CC: Sun C++ 5.11 SunOS_sparc 2010/08/13
> 
Compilation command line was:
CC -g -xdebugformat=dwarf test.cpp
Now attached is similar package compiled with the following command line:
CC -g -xdebugformat=dwarf -Qoption cg -h_gcc -xO0 -g test.cpp
(same compiler; as suggested by Sergio)
-- 
Regards,
Tomasz Grobelny

[-- Attachment #2: gdbtest.7z --]
[-- Type: application/octet-stream, Size: 69729 bytes --]

Re: sun compiler and gdb

[Tom Tromey]

>>>>> "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

Re: sun compiler and gdb

[Tomasz Grobelny]

On Thu, 10 May 2012 07:33:41 -0600, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "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.
> 
Do you think that this portion can be just ignored by gdb?

> After that you'd have to try again and see what other bugs crop up.
> 
Actually the behaviour on the two machines I have tested on is different.
Not yet sure whether this is a problem with compiler architecture (x86 vs
sparc) or gdb version (7.4.1 vs. 7.0.1), but it looks like this on
sparc/gdb 7.0.1:
> gdb -readnow ./a.out.sparc
GNU gdb (GDB) 7.0.1
(...)
This GDB was configured as "sparc-sun-solaris2.10".
Reading symbols from /login/sg209371/gdbtest/a.out.sparc...expanding to
full symbols...Die: DW_TAG_<unknown> (abbrev 9, offset 0x1bb)
  parent at offset: 0x197
  has children: TRUE
  attributes:
    DW_AT_name (DW_FORM_string) string: "basic_ostream" (is canonicalized)
    DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"
(not canonicalized)
    DW_AT_decl_file (DW_FORM_data1) constant: 2
    DW_AT_decl_line (DW_FORM_data1) constant: 74
Dwarf Error: Cannot find type of die [in module
/login/sg209371/gdbtest/a.out.sparc]
(gdb) quit
> 

With the relevant portion of dwarfdump looking like this:
<2><  443>	DW_TAG_SUN_class_template
		DW_AT_name                  basic_ostream
		DW_AT_SUN_part_link_name    nNbasic_ostream3CTACTB_
		DW_AT_decl_file             2
/opt/solstudio12.2/prod/include/CC/Cstd/ostream
		DW_AT_decl_line             74


Shouldn't unknown tag just be ignored? To me it looks like some compiler
specific extension.
I searched for other tags that might be compiler specific and here is the
list:
DW_AT_SUN_cf_kind
DW_AT_SUN_comdat_function
DW_AT_SUN_command_line
DW_AT_SUN_compile_options
DW_AT_SUN_func_offsets
DW_AT_SUN_language
DW_AT_SUN_link_name
DW_AT_SUN_part_link_name
DW_AT_SUN_pass_with_const
DW_AT_SUN_return_with_const
DW_AT_SUN_template
DW_AT_SUN_vbase
DW_AT_SUN_vtable
DW_AT_SUN_vtable_abi

Are any of these supported or (at least) explicitly ignored by gdb?
-- 
Regards,
Tomasz Grobelny

Re: sun compiler and gdb

[Tomasz Grobelny]

On Thu, 10 May 2012 18:37:41 +0200, Tomasz Grobelny
<tomasz@grobelny.oswiecenia.net> wrote:
> Actually the behaviour on the two machines I have tested on is
different.
> Not yet sure whether this is a problem with compiler architecture (x86
vs
> sparc) or gdb version (7.4.1 vs. 7.0.1), but it looks like this on
> sparc/gdb 7.0.1:
> 
It turned out to be a difference between gdb versions.
Does there exist any tool that would let me throw out those offending
sections from the executable file?
-- 
Regards,
Tomasz Grobelny

Re: sun compiler and gdb

[Tom Tromey]

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

Tomasz> Does there exist any tool that would let me throw out those offending
Tomasz> sections from the executable file?

Not that I know of.

Tom

Re: sun compiler and gdb

[Tom Tromey]

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

Tomasz> Reading symbols from /login/sg209371/gdbtest/a.out.sparc...expanding to
Tomasz> full symbols...Die: DW_TAG_<unknown> (abbrev 9, offset 0x1bb)

You want DIE 0x1bb...

Tomasz>   parent at offset: 0x197

... or perhaps 0x197 ...

Tomasz> With the relevant portion of dwarfdump looking like this:
Tomasz> <2><  443>	DW_TAG_SUN_class_template

But this appears to be DIE 0x443.

Tomasz> Shouldn't unknown tag just be ignored?

Yes, but I think what is happening is that you have one DIE which uses
DW_AT_type to refer to another DIE, and gdb doesn't know what to do with
the type DIE.

Tomasz> I searched for other tags that might be compiler specific and
Tomasz> here is the list:

Those are actually attributes; tags would be DW_TAG_something.

Tomasz> Are any of these supported or (at least) explicitly ignored by gdb?

AFAIK, no Sun extensions to DWARF are supported by gdb.
Generally they should be ignored, but as you've seen, there are
sometimes exceptions.  My impression is that this part of gdb is not
heavily tested.

Tom

Re: sun compiler and gdb

[Tomasz Grobelny]

On Thu, 10 May 2012 14:39:07 -0600, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net>
writes:
> 
> Tomasz> Reading symbols from
> /login/sg209371/gdbtest/a.out.sparc...expanding to
> Tomasz> full symbols...Die: DW_TAG_<unknown> (abbrev 9, offset 0x1bb)
> 
> You want DIE 0x1bb...
> 
> Tomasz>   parent at offset: 0x197
> 
> ... or perhaps 0x197 ...
> 
> Tomasz> With the relevant portion of dwarfdump looking like this:
> Tomasz> <2><  443>	DW_TAG_SUN_class_template
> 
> But this appears to be DIE 0x443.
> 
Actually it is DIE 443(dec) == 1bb(hex)
When you posted output from another dwarfdump version it took me a while
to figure out that one tool is giving numbers in hex and the other in dec.

> Tomasz> Shouldn't unknown tag just be ignored?
> 
> Yes, but I think what is happening is that you have one DIE which uses
> DW_AT_type to refer to another DIE, and gdb doesn't know what to do with
> the type DIE.
> 
Does the above comment about dec/hex values change your analysis here?

> Tomasz> I searched for other tags that might be compiler specific and
> Tomasz> here is the list:
> 
> Those are actually attributes; tags would be DW_TAG_something.
> 
Thanks for pointing that out - I am new to DWARF stuff and do not yet see
the difference between attribute, tag and die.

> Tomasz> Are any of these supported or (at least) explicitly ignored by
gdb?
> 
> AFAIK, no Sun extensions to DWARF are supported by gdb.
> Generally they should be ignored, but as you've seen, there are
> sometimes exceptions.  My impression is that this part of gdb is not
> heavily tested.
> 
I will have a look it they can somehow be removed...
-- 
Regards,
Tomasz Grobelny

Re: sun compiler and gdb

[Tom Tromey]

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

Tomasz> Actually it is DIE 443(dec) == 1bb(hex)
Tomasz> When you posted output from another dwarfdump version it took me
Tomasz> a while to figure out that one tool is giving numbers in hex and
Tomasz> the other in dec.

How weird.  Ok.

Tomasz> Does the above comment about dec/hex values change your analysis here?

Yeah.  The DIE in question has the tag DW_TAG_SUN_class_template.
gdb doesn't know about this.

I guess we could turn it into an error type or something... but that
isn't likely to be useful.  It might let you do a little debugging.

I suppose you could try it out.

Tom