Stabs versus dwarf

Stabs versus dwarf

The Sun compilers are currently undergoing a transition from stabs to dwarf. It sounds like the kind of undertaking where a +2 longsword might come in handy, but no. Leave your +2 sword in your three ring binder, and fire up your Sun Studio compilers to see what I'm talking about.

Stabs and dwarf are both different formats of debugging information. The Sun Studio 10 C compiler supports a command line option -xdebugformat=dwarf which tells the C compiler to spit out dwarf data instead of stabs. Eventually we'll be transitioning all the compilers to use dwarf by default. Dwarf has a number of advantages.

• It's much easier for platform independant tools to read dwarf. Instead of parsing the more esoteric stabs. (See below if you dare)
• Dwarf is actively being developed by a group of engineers working on compilers and tools. (See the working group's home page)
• Dwarf is more easily extendable, so that when you want to implement advanced features (say optimized code debugging) adding new data in a structured way is a piece of cake. New data can easily be ignored by tools that don't understand it.

stabs

In the beginning, the symbol information you needed to debug a program was simple. The name of the function, where it started, where (in the assembly code) line 7 turned into line 8, etc. You needed the names of the local variables and parameters and what their stack offsets are. That was about it. Then came C++. Then came C++ with templates. Then came function template instances with template arguments.

The stabs format for debugging information is basically a large array of fixed-size records. It has one enum, a few small integer arguments, and one string. So when extensions were added, the string just kept getting uglier and uglier. Here's an example from the stabs document:

template int tfex( B* x, A y ) { ... }

This turns into:

.stabs "__1cEtfex3CTACTB_6Fp10_i_:YTf
A:tYC(0,19);B:tYC(0,20); // define template params A and B
@;;__1cEtfex3CTACTB_6Fp10_i_
:T(0,3);(0,21)=*(0,20);(0,19); // returns int, gets (B*, A)
@;
x:p(0,21);y:p(0,19);// name function params x and y
@;1;1;",// line number of template source.
N_GSYM,0x0,0x0,0x0// rest of stab

Of course in the wild it just looks like:

(CSS aside: Boy, getting this long line to be wrapped by the browser to fit inside the width of the current page seems to be impossible! How disappointing. Maybe the roller blog system will pretty it up for me.)

.stabs "__1cEtfex3CTACTB_6Fp10_i_:YTfA:tYC(0,19);B:tYC(0,20) 
;@;;__1cEtfex3CTACTB_6Fp10_i_:T(0,3);(0,21)= 
*(0,20);(0,19);@;x:p(0,21);y:p(0,19);@;1;1;",N_GSYM,0x0,0x0,0x0

(Nope, I had to put line breaks in)

The things that look like (0,3) are references to types that might be defined in other stabs. If you want to know how dbx makes sense of all that goop, just take a look at the stabs document. All the really juicy bits are described under the Symbol Descriptors section.

If you want to see what the function name looks like in the source program, you can demangle it by running the output through c++filt.

% echo __1cEtfex3CTACTB_6Fp10_i_ | c++filt
int tfex<__type_0,__type_1>(__type_1*,__type_0)

You can see the stabs in a program by using dumpstabs a.out

dwarf

The dwarf format is more structured. You can see the output of dwarf using the dwarfdump command. Here is some example dwarfdump output:

% dwarfdump -a a.out
...
<1><  405>      DW_TAG_base_type
                DW_AT_name                  int
                DW_AT_encoding              DW_ATE_signed
                DW_AT_byte_size             4
...
...
<1><  713>      DW_TAG_class_type
                DW_AT_name                  c4
                DW_AT_decl_file             1
                DW_AT_decl_line             2
                DW_AT_byte_size             16
<2><  729>      DW_TAG_member
                DW_AT_name                  ii
                DW_AT_type                  <405>
                DW_AT_data_member_location  DW_OP_plus_uconst 0
                DW_AT_accessibility         DW_ACCESS_public
<2><  741>      DW_TAG_member
                DW_AT_name                  dd
                DW_AT_type                  <562>

It's much easier to read the output of dwarfdump than the output of dumpstabs. The numbers like <405> point to other TAGs in the same dwarf file. So you can just search for that number in the file, to see what the type of that member is.

Implementing Dwarf support in the Sun compilers has occupied a good chunk of my time for the last several years (on and off), so you're bound to hear more about it from me. Stay tuned.

Posted by Chris Quenelle ( Jun 07 2005, 07:51:56 PM PDT ) - Permalink - Comments [1] - Dbx