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 Mon, 2009-04-13 at 11:32 -0700, Roland McGrath wrote:
> > So what we could do at this time is make sure sym.value is between the
> > reported base of the module and the end of the module as returned by
> > dwfl_module_info() Then at least we only process "sane values" (even
> > though they might not be real function or data symbols).
> 
> That seems like a reasonable heuristic.

Something I thought of later. Does that also hold for kernel modules,
which are ET_REL? If I understood correctly in theory the separate
sections could be allocated completely separately from the module base
and end. Does libdwfl in offline mode guarantee that all ET_REL sections
have a base themselves that falls inside the module start/end address?
Or did I misunderstand how ET_REL section addresses are allocated?

> Or, you could use getelf
> and getscn and check for SHF_ALLOC--a real, proper check, not a heuristic
> guess.  You'd definitely want that code only under _ELFUTILS_PREREQ, since
> it introduces undesireable performance effects.

So, for a different reason, since I needed the address range a ET_REL
section covers for which we build a symbol table, I am now using
dwfl_module_address_section () and then gelf_getshdr () on the returned
Elf_Scn to get at the details of the section. Does this also introduce
undesirable performance effects?

Also, this interface could probably be slightly friendlier.
What I am doing is:
- Loop through symbols with dwfl_module_getsymtab () and
  dwfl_module_getsym() (use 
- Save the original symbol address for later use (see below).
- Transform the symbol address to a relative one with
  dwfl_module_relocate_address().
- Get the section name with dwfl_module_relocation_info(), which also
  can give me the elf section index (same as dwfl_module_getsym()
  already returned).
- Use the saved symbol address to call dwfl_module_address_section () to
  get the Elf_Scn (again the address is relocated and again I get the
  section relocation base).
- Call gelf_getshdr () to get at the section header which contains the
  section size.

Is there a way to shorten this call chain?

Cheers,

Mark


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