WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
On Thu, 03 May 2012 03:49:41 -0300, 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
>> 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
DW_AT_name (DW_FORM_string) string: "basic_ostream" (is canonicalized)
DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"
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]
Starting program: /login/sg209371/a.out
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Program exited normally.
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).