This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]