Obtaining current address for .stabs

Daniel Jacobowitz drow@mvista.com
Mon Mar 4 13:16:00 GMT 2002


On Mon, Mar 04, 2002 at 08:54:32PM +0000, John Levon wrote:
> 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.

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.

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.

> > 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.

Is it really?  If the symbol is local to the file and depends on
__FUNCTION__ and __LINE__... well, no, inlining would mess that up. 
Hmm.

> 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.

> .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 :)

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"
	.set a = .
	.previous

	.stabs "foo lock:F=(0,20)", 36, 0, 6, a

	blah

	.section ".text.lock"
	.set b = .
	.previous

	.stabs "", 36, 0, 0, b - a
> 
> > 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.

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.

> > > 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.

I can't really say where it's coming from to get the value you see
(though I did not look too closely at your example, sorry).  '.' is the
current point in the current section, generally...

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



More information about the Binutils mailing list