Re: PR10000: emit _stp_relocate* calculations correctly for kernel/module global $data (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9-238-g432f054)

[Roland McGrath <roland at redhat dot com>]

> > >   { 0xffffffffffeda000, "__evoke_link_warning_fdetach" },
> > >   { 0xffffffffffeda040, "__evoke_link_warning_getwd" },
> > 
> > I don't know where those crazy values come from.  These symbols are local,
> > have actual value of zero, and are in non-SHF_ALLOC sections.
> 
> The original values are not all zero (the second one actually is 0x40).

Ah, yes.  For some reason the .gnu.warning.getwd section is doubled, with
its first and second parts pointed to by two different local symbols called
__evoke_link_warning_getwd (i.e. must have been from different .o files in
the libc build).  Well, that is neither here nor there.  The st_values are
quite meaningless to your context, being symbols in non-SHF_ALLOC sections.

> The crazy values come from then transforming the value with
> dwfl_module_relocate_address().

I don't follow.  You mean you got some value from dwfl_module_getsym, right?

I think it's giving you st_value + main.bias, basically.  (That's a bug.)
Then this bogus address happens to lie somewhere very early in the text, so
that it's actually an address in the ELF header or something.  Then
dwfl_module_relocate_address tells you what that is relative to the
earliest proper text section (so it can be negative), or something like that.

> Basically we are just doing the following from a dwfl_getmodules()
> callback:
[...]
>       const char *name = dwfl_module_getsym(m, i, &sym, NULL);
s/NULL/&shndx/
>           && !(sym.st_shndx == SHN_UNDEF
>                || sym.st_shndx == SHN_ABS))

You might not want to exclude SHN_ABS, really.  
That is things like _edata and _end.

> So, we need to extend the check to include the section flags of the
> given sym.st_shndx. 

For anal reasons, the &shndx filled by dwfl_module_getsym is what you use
for the actual symbol, not st_shndx--but st_shndx is what you test for the
SHN_* constants.

> I seem to remember that calling dwfl_module_getelf() is considered
> expensive.

Right, because it causes eager relocation of all the sections.  (This was
added for the benefit of parsing the old markers table sections in .ko
files, and I don't think anything actually wants that relocation done now
that stap just uses the Module.markers file.  But now that's the libdwfl API.)

> Do I need to get at the elf file myself and extract with
> elf_getscn by hand, or is there something smarter to do? 

It's worse than that.  In the general case, the symtab might come from
either the main file or the separate debug file.  You have to know which it
is to make sense of a section index.  The indices of the SHF_ALLOC sections
should always match those in the main file, but the main file's symtab
won't have the non-allocated sections' headers at all.  It probably works
to just see the shndx is >= main's e_shnum, but that feels real fragile.

A first thought was to add a variant dwfl_module_getsymscn that yields an
Elf_Scn * instead of the index.  But, for general-purpose use where you
might look at sh_addr, that leaves you still having to figure out what bias
(or relocation) to apply to the sh_addr value.

So a second thought was to make it dwfl_module_getsymshdr instead, just
filling in a GElf_Shdr for you (with sh_addr adjusted).  But that too is
getting rather clunky.

Another thought is to say that dwfl_module_getsym is intended mainly for
symbols that translate to an actual address (i.e. in SHF_ALLOC sections or
SHN_ABS).  Then all one is really looking for is an indicator whether the
symndx you asked about has an st_value meaningful as an address or not.
I've done that on the roland/getsym branch in elfutils git, if you want to
take a look.


Thanks,
Roland