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 Fri, 2009-04-17 at 15:27 -0700, Roland McGrath wrote:
> You need to know the runtime set of addresses that fall within each module.
> For that you don't need section sizes per se.  You need an address->module
> mapping at runtime that works for what runtime modules really are.

Yes.

> For non-ET_REL, modules are contiguous.  (Even if we really supported
> discontiguous modules, you just need to know the PT_LOAD set, which is easy
> to find at runtime and was so found already in doing the loading.  i.e.,
> it is the same as the file mapping tracking you used to decide this was the
> module to probe, etc.)

Using the tracker is a nice trick. But in that case we already know the
size since dwfl_module_info() gives us start and end.

> For ET_REL, there isn't a universal meaningful kind of thing, so we are
> just talking about the specifics of the runtime ET_REL loader you are
> working with, i.e. Linux kernel modules.  Linux kernel modules are loaded
> in two chunks, whose bounds are handy in the 'struct module': one at
> module_core for core_size bytes; the other at module_init for init_size
> bytes (which are cleared after the load-time initializer has run).

OK, that is simpler than I thought. I had expected the sections to be
split up more (data read-only/write vs code, etc sections).
Unfortunately we don't seem to have access to the struct module data
since we are a kernel module and the interfaces aren't exported. So we
use the /sys/module/<modname>/sections/<secname> files, which only gives
us the section start addresses.

This is the documentation of runtime/staprun/staprun.c
(send_a_relocation):

/* Send a variety of relocation-related data to the kernel: for the
   kernel proper, just the "_stext" symbol address; for all loaded
   modules, a variety of symbol base addresses.

   We do this under protest.  The kernel ought expose this data to
   modules such as ourselves, but instead the upstream community
   continually shrinks its module-facing interfaces, including this
   stuff, even when users exist.
*/

Cheers,

Mark


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