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)


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

struct module is defined in <linux/module.h>.  __module_address is
exported.  That does address->module mapping, which is the part of the
problem we are talking about.

Also, find_module is exported, for looking up by name.
Also, the struct module * is passed to register_module_notifier callbacks.
So you have it right at hand when tracking a module being loaded/unloaded.

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, even though
the head of the list is private to module.c ("static LIST_HEAD(modules);").

struct module_sec_attrs is indeed private to module.c so that you can't get
the section info easily inside the module, and have to get that via /sys.


Thanks,
Roland


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