Trying to probe a module by providing the full path to it in the 'module' probe component does not work: $ cat mymodule.c #include <linux/kernel.h> #include <linux/module.h> #include <linux/init.h> static int __init mymodule_init(void) { printk(KERN_INFO "Hello world!\n"); return 0; } static void __exit mymodule_cleanup(void) { printk(KERN_INFO "Cleaning up module.\n"); } module_init(mymodule_init); module_exit(mymodule_cleanup); $ make $ stap -e 'probe module("/home/vm/codebase/systemtap/systemtap/tmp/mymodule.ko").function("mymodule_init") { println(ppfunc()) }' -c 'sudo insmod mymodule.ko && sudo rmmod mymodule.ko' $
Created attachment 7645 [details] potential patch This occurs because of name mismatches: - Both the .name and .path members of the corresponding _stp_module struct are set to the full path of the module. - When the module notifier is called from the kernel, only the module name is passed, path information is lost. So when we try to update section addresses, we fail to match against any of the structs and thus fail to update. - Even if the above is fixed, the dwarf_derived_probe_group emits in the corresponding stap_dwarf_probe the full path for the .module member. This also causes a mismatch to occur when trying to relocate the probe address. The patch given fixes these issues by retrieving the actual module name from the .gnu.linkonce.this_module section and using that name when emitting the _stp_module struct and stap_dwarf_probe structs. NB: note the TODO item in the patch re. calculating the proper offset for the module name.
*** Bug 14596 has been marked as a duplicate of this bug. ***
(In reply to Jonathan Lebon from comment #1) > NB: note the TODO item in the patch re. calculating the proper offset for > the module name. Looking at this more deeply now, this is not as easy as it seems. The struct is defined in <linux/module.h> but clearly userspace apps shouldn't include that. We could instead simply rely on DWARF information and retrieve the DW_AT_data_member_location attribute from the name DW_TAG_member. But this assumes we have DWARF info to begin with. Since we are now able to probe functions without DWARF info, this would be a sad requirement to add. Another way would be to defer this work until runtime, at which point we can directly use offsetof(), although I'm not too sure how feasible ELF inspection is there. The deferring also adds complexity which I'd rather avoid. The easy way out is to go the 'heuristicky' way and simply assume that the module name is the $(basename $path .ko). This is more or less what elfutils does but in reverse (i.e. find the ko file from the module name, see libdwfl/linux-kernel-module.c). We can also do a combination of the two, i.e. if we have DWARF, then use that, otherwise just use the basename. Thoughts?
(In reply to Jonathan Lebon from comment #3) > The easy way out is to go the 'heuristicky' way and simply assume that the > module name is the $(basename $path .ko). This is more or less what elfutils > does but in reverse (i.e. find the ko file from the module name, see > libdwfl/linux-kernel-module.c). Done in commit 4766b1e.