This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Obtaining current address for .stabs
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.