This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
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)
- From: Mark Wielaard <mjw at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Thu, 09 Apr 2009 00:52:11 +0200
- Subject: 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)
- References: <20090327155519.19560.qmail@sourceware.org> <1239187983.3146.55.camel@fedora.wildebeest.org> <20090408124044.A0418FC351@magilla.sf.frob.com>
Hi Roland,
On Wed, 2009-04-08 at 05:40 -0700, Roland McGrath wrote:
> > Allowing STT_OBJECTS also allowed in some odd creatures that don't seem
> > to be real symbols. In my case in libc.so the following things got
> > really malformed (negative) addresses leading to the infamous "error:
> > integer constant is too large for ?long? type" in stap-symbols.h:
> >
> > { 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).
The crazy values come from then transforming the value with
dwfl_module_relocate_address().
> > If there is a better way to recognize these (they have a "normal"
> > st_shndx as far as I can tell) please let me know.
>
> Any symbol in a non-SHF_ALLOC section should be of no concern to you.
> All sorts of symbols in non-allocated sections (e.g. in .debug_*
> sections) might sometimes be in an unstripped .symtab, not just these
> (which are in link-time magic sections).
Aha. OK. Thanks.
Basically we are just doing the following from a dwfl_getmodules()
callback:
int syments = dwfl_module_getsymtab(m);
for (int i = 0; i < syments; ++i)
{
GElf_Sym sym;
const char *name = dwfl_module_getsym(m, i, &sym, NULL);
if ((GELF_ST_TYPE (sym.st_info) == STT_FUNC ||
GELF_ST_TYPE (sym.st_info) == STT_OBJECT)
&& !(sym.st_shndx == SHN_UNDEF
|| sym.st_shndx == SHN_ABS))
{
Dwarf_Addr sym_addr = sym.st_value;
const char *secname;
int ki = dwfl_module_relocate_address (m, &sym_addr);
secname = dwfl_module_relocation_info (m, ki, NULL);
// ...
}
}
So, we need to extend the check to include the section flags of the
given sym.st_shndx. Now I see dwfl_module_getsym already (through
__libdwfl_relocate_value) gets the section header and even compares it
to SHF_ALLOC. But I don't see a way for the caller to get at this value
to use in a situation as the above. Do I need to get at the elf file
myself and extract with elf_getscn by hand, or is there something
smarter to do? I seem to remember that calling dwfl_module_getelf() is
considered expensive.
Thanks,
Mark