Obtaining current address for .stabs

Daniel Jacobowitz drow@mvista.com
Mon Mar 4 21:09:00 GMT 2002


On Mon, Mar 04, 2002 at 09:55:42PM +0000, John Levon wrote:
> On Mon, Mar 04, 2002 at 04:16:20PM -0500, Daniel Jacobowitz wrote:
> 
> > What are you doing that particularly needs stabs here?  Are you trying
> > to get backtraces on deadlock or some such?  Otherwise a table in some
> > other format might be much simpler.
> 
> It is so that profile samples can be accurately attributed back to the
> original (for example) spin_lock(&lock) call that caused the contention
> i.e. a particular source line.
> 
> this is currently possible by hand by dumping the profile output of
> .text.lock and using objdump --disassemble -j .text.lock, and figuring
> it out backwards.
> 
> But this is a chore, and is what I'm trying to avoid. I can't
> /radically/ re-work what the kernel does because I'll need to maintain
> the patch, and I want it to be usable on actual production systems.

No need to do it this way at all.  I can give you a simpler solution, I
think.  And this even fixes your problems with stabs: Use local labels.

        .stabs  "a:F(0,20)",36,0,0,3f
        .section ".text.locks"
3:
        nop
        .previous

That works correctly, as best I can see.

An easier thing to do may be:
        .text
        nop
        nop
        nop
        .section ".text.lock"
3:
        nop
        .previous

        .section "lock.address.table"
        .long 3b
	.long __LINE__
	.pointer-to-__FILE__-string

(I think the BUG() mechanism now provides a unique pointer to a
__FILE__ somewhere...)

Both of these do in fact work :)  I believe all Linux platforms have
forward/backward local labels.

> > I know lots of people (and lots of compilers, including gcc 3.1 on all
> > Linux targets!) that do not use stabs.  This will not work for them.
> 
> I'm pretty new to stabs, as you can tell - why does the gcc version
> affect what I output as inline asm ? Does it somehow strip any stabs
> directives ? Or is it that the toolchain as a whole will not create
> .stab and .stabstr ?
> 
> (I suppose I will have to look up what gcc3.1 uses for debug info ;)

DWARF-2.  Stabs is a crufty, underdocumented, hard-to-parse format. 
DWARF-2 is well defined, and lets us actually express the sorts of
things it is useful to express.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer



More information about the Binutils mailing list