PR10000: emit _stp_relocate* calculations correctly for kernel/module global $data

[Roland McGrath]

> ... but that is designed to run with module_mutex held, which was only
> only recently module-exported, so using it generally incurs a race
> condition.

If "generally" means on older kernels, sure.  This stuff will always be a
moving target.

> > Every module can access its own struct module * with THIS_MODULE.
> > So a stap-generated module can do this.  You can start with your
> > own, and iterate over the list that links them all together [...]
> 
> I seem to recall some other problem (portability? locking?) with this
> approach.

You do have to worry about locking for that as for find_module et al, sure.
There are some unlocked uses, however.  So you should be safe if you follow
those models.  Those use list_for_each_entry_rcu with preempt disabled,
e.g. __module_address.

There is also the /proc/modules list, which shows ->module_core and ->core_size.

There is also /sys/module/sections/.gnu.linkonce.this_module, which has the
kernel address of the magic section that maps to THIS_MODULE.

There are many ways to skin this cat at run-time (in kernel or in staprun).
I don't think that determining individual section sizes is necessary for
any good choice.


Thanks,
Roland