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)
> 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
- References:
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)