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)


> 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. 

When the ET_REL module is actually loaded at runtime, any placement of each
section is possible (from the libdwfl perspective, the general case).  In
actual fact, the kernel lays out everything in a module close together.

> 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.

> 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.

> 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.

> Also, this interface could probably be slightly friendlier.

That might not get much better that soon.  My intent is to get a clear
handle on all your usage patterns and make that be easier and more natural
in the eventual proper C++ interfaces.  (Having those gel so stap could
convert to using them is a few months away.)

> 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?


Thanks,
Roland


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