Re: sun compiler and gdb

[Tomasz Grobelny <tomasz@grobelny.oswiecenia.net>]

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