Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> Development Tools >> Solaris and Linux Development Tools

Studio 12 C++ debugging symbols can't be read by gdb?

Studio 12 C++ debugging symbols can't be read by gdb?

The simple C++ test program:

/* vec.cpp */

#include <iostream>

#include <string>

#include <vector>

int main()

{

std::vector<int> v;

v.push_back(1);

std::cout << *v.begin() << std::endl;

return 0;

}

Compiling by Sun C++ with -g option:

$ sunCC -g -o vec vec.cpp

Then load vec by gdb:

1. Sun Studio 12 for Linux, on a Debian unstable box.

$ gdb -v

GNU gdb 6.6-debian

$ gdb --quiet ./vec

Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".

(gdb) list

Die: DW_TAG_<unknown> (abbrev = 8, offset = 6237)

has children: TRUE

attributes:

DW_AT_name (DW_FORM_string) string: "basic_ostream"

DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"

DW_AT_decl_file (DW_FORM_data1) constant: 5

DW_AT_decl_line (DW_FORM_data1) constant: 73

Dwarf Error: Cannot find type of die [in module /tmp/vec]

(gdb) b main

Die: DW_TAG_<unknown> (abbrev = 8, offset = 6237)

has children: TRUE

attributes:

DW_AT_name (DW_FORM_string) string: "basic_ostream"

DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"

DW_AT_decl_file (DW_FORM_data1) constant: 5

DW_AT_decl_line (DW_FORM_data1) constant: 73

Dwarf Error: Cannot find type of die [in module /tmp/vec]

(gdb) info functions

Die: DW_TAG_<unknown> (abbrev = 8, offset = 6237)

has children: TRUE

attributes:

DW_AT_name (DW_FORM_string) string: "basic_ostream"

DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"

DW_AT_decl_file (DW_FORM_data1) constant: 5

DW_AT_decl_line (DW_FORM_data1) constant: 73

Dwarf Error: Cannot find type of die [in module /tmp/vec]

(gdb)

2. Sun Studio 11 for Solaris x86, on a Solaris 8 box.

$ gdb -v

GNU gdb 5.0

$ gdb --quiet ./vec

(gdb) list

1/***************************************************************************

2*

3* vector.cc - Non-inline definitions for the Standard Library vector class

4*

5***************************************************************************

6*

7* Copyright (c) 1994

8* Hewlett-Packard Company

9*

10* Permission to use, copy, modify, distribute and sell this software

(gdb) list main

No line number known for main.

(gdb) b main

Breakpoint 1 at 0x8051c06

(gdb) info functions

All defined functions:

File vec.cpp:

void __1cDstdJbad_alloc2T5B6M_v_(struct <unknown> *);

void __1cDstdJbad_alloc2T6M_v_(struct <unknown> *);

void __1cDstdJbad_alloc2t6M_v_(struct <unknown> *);

void __1cDstdJexception2T5B6M_v_(struct <unknown> *);

void __1cDstdJexception2T6M_v_(struct <unknown> *);

void __1cDstdJexception2t6M_v_(struct <unknown> *);

int main(struct <unknown>, struct <unknown>, struct <unknown>,

struct <unknown>, struct <unknown>, struct <unknown>, struct <unknown>,

struct <unknown> *, struct <unknown> *, struct <unknown> *,

nJreference(0,23), struct <unknown> *, struct <unknown>,

struct <unknown> *, struct <unknown> *, struct <unknown> *, int *, int *,

struct <unknown> *, int *, nJreference(0,23), struct <unknown>,

struct <unknown>, struct <unknown>, struct <unknown>, struct <unknown>,

struct <unknown>, nJsize_type(0,28), struct <unknown>, struct <unknown>,

struct <unknown>, nJsize_type(0,28), struct <unknown>, struct <unknown>,

int *, nJreference(0,23), struct <unknown>, int *, nJsize_type(0,49),

struct <unknown>, struct <unknown>, struct <unknown>, struct <unknown>,

struct <unknown>, nJsize_type(0,49), int *);

static <unknown type> N(<unknown type>);

Type <return> to continue, or q <return> to quit

Non-debugging symbols:

00000000 __fsr_init_value

(gdb)

Is't a bug of Sun CC or gdb?

[4414 byte] By [hzhra] at [2007-11-27 6:58:44]
«« building HelloWorld and getting error...
»» TextField Listener
# 1

The debuggers use different debug data. Sun Studio dbx can read the debug info produced by gcc/g++, but gdb does not know about Sun Studio debug data.

dbx has a mode where it recognizes gdb commands, whether debugging code from gcc or Sun Studio:

% dbx a.out

(dbx) gdb on

So why not just use dbx? It's a much better debugger. :-)

clamage45a at 2007-7-12 18:49:15 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 2

But C debugging symbols is OK. gdb can list source, set breakpoint by symbol name:

#include <stdio.h>

int main()

{

printf("Hello, world\n");

}

$ gdb --quiet ./hello

Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".

(gdb) list

1#include <stdio.h>

2

3int main()

4{

5printf("Hello, world\n");

6}

7

(gdb) b main

Breakpoint 1 at 0x8048356: file /tmp/hello.c, line 5.

Actually, I didn't care whether gdb can list C++ source or not, but I expect gdb can set breakpoint by symbol name. If I use C++ mangled symbol name, it's OK:

(gdb) b __1cDstdGvector4Cin0AJallocator4CiJpush_back6Mrki_v_

Breakpoint 2 at 0x8048fa6

but why b main failed?

(gdb) b main

Die: DW_TAG_<unknown> (abbrev = 8, offset = 6288)

has children: TRUE

attributes:

DW_AT_name (DW_FORM_string) string: "basic_ostream"

DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"

DW_AT_decl_file (DW_FORM_data1) constant: 5

DW_AT_decl_line (DW_FORM_data1) constant: 73

Dwarf Error: Cannot find type of die [in module /home/hzhr/Projects/test/preprocess/vec]

$ nm vec | grep main

U __libc_start_main@@GLIBC_2.0

08048dd0 T main

And I must say sometimes, gdb is more useful then dbx.

hzhra at 2007-7-12 18:49:15 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 3

The C ABI (binary interface) is the same for all compilers, and (except for some special cases in C99) C names are not mangled

The C++ ABI is different for all compilers. To help ensure that incompatible binaries don't accidentally link, compilers use different name mangling schemes.

gdb expects to see the g++ ABI, including g++ mangled names. Sun Studio does not currently produce the g++ ABI, so gdb can't do its job very well.

clamage45a at 2007-7-12 18:49:15 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 4
We have just started implementing some compiler flags that willmake Sun C++ work better with gdb. But it will never be 100%. Sunworks hard to make dbx compatible with both suncc and gcc, but nobody is working on gdb to do the same.
ChrisQuenellea at 2007-7-12 18:49:15 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 5

I don't think it's a ABI problem, since if the test C++ programe is compiled with no debugging information, gdb can set breakpoint by mangled names:

$ sunCC -o vec vec.cpp

$ gdb --quiet ./vec

Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".

(gdb) b main

Breakpoint 1 at 0x8048d49

(gdb) info functions main

All functions matching regular expression "main":

Non-debugging symbols:

0x08048bf4 __libc_start_main@plt

0x08048d40 main

(gdb) info functions insert

All functions matching regular expression "insert":

Non-debugging symbols:

0x08049170 __1cDstdGvector4Cin0AJallocator4CiM__insert_aux6Mpirki_v_

(gdb) b __1cDstdGvector4Cin0AJallocator4CiM__insert_aux6Mpirki_v_

Breakpoint 2 at 0x8049179

As you can see, the main function is never been mangled in C++ program with debugging info, but still can't set breakpoint.

hzhra at 2007-7-12 18:49:15 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 6

Sun compilers utilize extended DWARF (debugging information standard), especially in the area of C++ templates. Apparently, gdb doesn't handle these extensions. You can use 'dwarfdump' utility that comes with Sun Studio to find out what exactly is different with regards to DWARF if you're curious.

MaximKartasheva at 2007-7-12 18:49:15 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
Development Tools
Solaris and Linux Development Tools

Development Tools Hot Topic

Development Tools

All Classified