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


> OK, I see. Now reading back in the thread I think what you are saying is
> to use /proc/modules instead of /sys/module/sections since /proc/modules

I tried to cite all the places you could get the runtime module segment
bounds.  I'm not saying exactly which of those to use.  

I am saying that runtime module segment bounds is all you need and that you
should not be trying to do anything for which you would care about
individual sections' bounds.

> Then we can treat these just like ET_DYN shared libraries.

Almost.  The kernel modules have two "floating" segments (core and init),
i.e. the offset between core and init addresses is not static.  So there
are two separate contiguous chunks to consider at runtime.

In ET_DYN objects, there might be several segments in theory (not just
magically two), but there is a static offset between them.  So there is
only one contiguous address range to consider.

> The only trick would be to track the init segments (assuming we support
> probing those at the moment).

I don't know what the status of init probes is.  The init segment exists in
memory only during the window where the initializer code runs.  i.e.,
between MODULE_STATE_COMING notifier and MODULE_STATE_LIVE notifier
(or MODULE_STATE_GOING instead if the initializer fails).

Just using the notifier, it would be simple enough to track which modules
are in the middle of init and hold their struct module pointers.  (There
won't often be more than one at a time, but there could be.)  From there,
the ->module_init and ->init_size fields are handy.

> Is it possible to find out during offline mode which sections will go
> into which kernel segment (core/init)? That would probably simplify some
> of our code.

There is nothing that libdwfl or anything generic to ELF stuff knows about
this.  So again you would just encode specific knowledge about the Linux
kernel module loader in code specific to Linux kernel modules.  It just
segregates them by which sections have names beginning with ".init".

But I don't see why you need to know that at all.  At runtime, you need to
know which module a PC belongs to, end of story.

At stap module load time, you need to apply the correct adjustment to each
address value, no different from probe PCs.  At translation time, you need
to know what to tell that load time logic to do, i.e. the libdwfl
relocation base info, no different from probe PCs.

The only reason I can see for knowing whether an address is in the init
segment is for probe insertion.  There you need to know which probe
addresses can no longer be touched after the module initializer has run.

I guess for unwind data you could segregate your data by segment, and then
free the data about init-segment addresses when the init segment itself has
been freed.  But I am guessing you do not pick apart and re-pack the unwind
data at translation time enough to do that.


Thanks,
Roland


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