Reading the stabs.index section of Shared Libs

Hi there.

In order to produce developer-friendly stack-traces, I'd like to read the stabs info from our own projects to map the stack offsets to actual code lines.

So far, I've sucessfully written the reader to handle the lazy stabs inside our object files, and I get the relevant mapping (using N_SLINE, N_FUN and N_SO). But I don't have much luck trying to find these actual .o files from the shared libs (using the N_OBJ stabs contained in the ".stab.index" section of the shared library).

It looks like Sun Studio 11 (maybe earlier versions too) writes the stabs in an odd format in our shared-lib, so that only the beginning of the section is correct (only the one covered by the first N_UNDF) . After a while, the offset to the strings get wrong, even using the "correct" algorithm of adding the offset contained in the previous N_UNDF stab.

So, I can read all the information correctly, except for the actual strings for each stab. I had a look at some other stab-readers (gdb and valgrind), and they suffer from the same issue as my code. Actually, even an [i]objdump -G mySharedlib.so[/i] produces the same incorrect output. But obviously, there is a way of find the correct string pointers, as the [i]dumpstabs [/i]tool works perfectly.

Does anyone have any pointer to the actual trick needed to read the stabs ? I've already read "The stabs debug format", and the document provided by Sun (and linked from Chris Quenelle's blog): http://developers.sun.com/tools/cc/documentation/ss10_docs/stabs.pdf

Cheers

[1566 byte] By [Lam.sa] at [2007-11-26 20:38:19]
# 1

First of all, I should start by saying that in Sun Studio 12 all the

Sun compilers will generate dwarf as the default debugging format,

and you should be able to use the GNU binutils "addr2line" utility

to query the line number information. The dwarf information produced

by Sun Studio 11 (C compiler, for example) has a glitch that makes

it incompatible with addr2line, but the glitch is fixed in our development

release, and Sun Studio 12 (when it comes out) will work with addr2line.

On Solaris, the addr2line utility is available as "gaddr2line".

But I realize that stabs processing is also useful for the time being.

Here are my ideas for what might be going wrong.

If there are stabs that resulted from COMDAT functions then there are

special formatting issues. The C++ compiler uses COMDAT to implement

templates. The stabs.pdf document describes how COMDAT affects

stabs. Search for the word COMDAT in the document. Because comdat

ELF sections are merged at link-time, it might also help to run

elfdump and dumpstabs on some of the .o files that are being put into

your library as a way of understanding what's going on.

Specifically, the string table offsets need special processing around

any index stabs that result from comdat sections, so I suspect

that's what's causing problems.

ChrisQuenellea at 2007-7-10 1:55:01 > top of Java-index,Development Tools,Solaris and Linux Development Tools...