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