Obtaining current address for .stabs

John Levon levon@movementarian.org
Mon Mar 4 13:55:00 GMT 2002


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.

> 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 ;)

> > That would work perfectly (and in fact 2.4.18 does something similar).
> > The problem with that is that it's impossible to generate valid symbol
> > names that are unique, which is why I turned to stabs.
> 
> Is it really?  If the symbol is local to the file and depends on
> __FUNCTION__ and __LINE__... well, no, inlining would mess that up. 

Yes, __FILE__,__LINE__ has a similar problem. Something like
__ORIGINAL__FUNCTION__ for gcc would be perfect, but I'm not going to
ask for that ;)

> > The 2.4.18 approach via .ifndef that you suggest here means that some
> 
> I have no idea what you're talking about, so obviously I didn't suggest
> such a thing.

2.4.18 generates something like :

	.ifndef __text_lock_semaphore
	__text_lock_semaphore:
		cmpb ...

for each point. So really I meant to say it's similar to what you
suggest - sorry.

> Using .set ought to give you the information you need; you might want
> to investigate the failure.  I think what you suggested was roughly
> like this:
> 	.section ".text.lock"
>	...

Yes, I will try it in the form you suggest - thanks.

> You're using an older linker.  I don't know how old, but your assert is
> a hundred or so lines off from where it is in CVS.  Not having the
> N_FUN stab would only bite you with a fairly current binutils.

I see.

You've been most helpful

thanks
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.



More information about the Binutils mailing list