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 Thu, 2009-04-16 at 13:53 -0700, Roland McGrath wrote:
> > Does libdwfl in offline mode guarantee that all ET_REL sections
> > have a base themselves that falls inside the module start/end address?
> 
> In offline mode, libdwfl lays out the sections all next to each other so
> that there is a single contiguous module start..end.

That is a nice feature to have in offline mode.

> > 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 not clear on why you are doing this.  Why do you need this range?
> I'd expected you'd just use dwfl_module_relocate_address and be done with it.
[... rearranged ...]
> > What I am doing is:
> > - Loop through symbols with dwfl_module_getsymtab () and
> >   dwfl_module_getsym() (use 
> 
> For what again?  Are you storing the whole symtab for runtime lookups or
> something?

Yes, we build a table of all function symbols, sorted by (relative)
address, per relocation section, so at runtime we can easily lookup a
symbol name given an address (keep track of where the sections are
placed at runtime, then do a binary search through that table). We also
need the size of the relocation sections to lookup other info for an
address at runtime we associate with a module, like the unwind tables.

> > 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?
>
> Yes, it applies relocs to the section contents before returning.

That is a pity, but this is only for a relocation section that contains
an address of a symbol we are interested in (which admittedly is a
larger number now that we also collect non-function symbol addresses).
But I don't see any other way to get the individual relocation section
sizes (in the ET_EXEC and ET_DYN cases it is easy, since then the
relocation section size equals the module size for which we can get the
start and end addresses through dwfl_module_info).

Cheers,

Mark


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