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.

Comments:

Good blog Chris. I was thinking someone needed to blog about this, glad you took up the task.

Posted by Kelly O'Hair on August 21, 2005 at 05:18 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Chris Quenelle

Search

Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today