Re: Obtaining current address for .stabs

[John Levon <levon at movementarian dot org>]

On Mon, Mar 04, 2002 at 03:11:24PM -0500, Daniel Jacobowitz wrote:

> > I need to manually code some .stabs data via inline asm with gcc.
> 
> Why?  Why, God, why?

To generate values I can look up later.

> Stabs does not have any support for multiple sections.  Anything
> working is a bit of luck.  Use DWARF-2 and address ranges (which you
> are not going to be able to do in inline assembly.).

ok, so that's no good ...

> > #define __stabs_text_lock_asm(l)               \
> >        ".section .text.lock,\"ax\"\n"          \
> >        ".stabs \"" __FILE__ "\",100,0,0,.\n"   \
> >        ".stabs " "\"text_lock_" #l             \
> >        " at " __FILE__                         \
> >        " line " __STRINGIFY(__LINE__)          \
> >        ":F(0,20)\",36,0,0,. \n"                \
> >        ".previous\n"
> > 
> > Now this is inserted before linux kernel code that generates actual
> > code in the .text.lock section.
> 
> You're being very complicated here.  Why mess with sections?  .stabs do
> not generate code; put them interspersed with .text.  Have them
> reference a symbol declared in .text.lock in the following code.  What
> happens then?

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.

The 2.4.18 approach via .ifndef that you suggest here means that some
.text.lock code does not have a symbol range for it, which means
profiling tools will wrongly attribute samples in that range to the
/previous/ symbol in .text.lock. This is obviously not ideal, since the
wrong attributions depend on the order things are linked into the final
vmlinux.

Basically I want to have useful data for example "(&lock) at
some_file.c line 89" for each little piece of code that gets added to
.text.lock (although since kernel 2.4.18 it ends up in subsection 1 of
.text anyway).

This is essentially a debugging tool, it doesn't have to be cleanly done
(although I would prefer it :)

> You may need an empty (ending) N_FUN stab if you don't want the linker
> to mangle you later.

This actually ends up working i.e. the kernel links and runs just fine.

> > given the differences, it seems that the .stabs data (which ends up in
> > .stab and .stabstr) is advancing the location counter, even though it
> > ends up automagically in a different section. For example it looks like
> > 12 is added on for every file (100) entry, and 8 for every normal
> > function (36) entry.
> 
> Conclusion here is almost certainly wrong.

OK, thanks. I thought that didn't make much sense. So where is the value
for "." in the .stabs entry coming from ? There is a strict correlation
between a change in which file vs. another entry in the same file (I
assumed we see the +20 offset only once per file since the 100 .stabs
entries are identical and get merged, yes ?)

I accept what I am doing is pretty much a perversion of the feature.
However I would be grateful if you can suggest a way to get this
working, or point me towards another alternative.

thanks,
john

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