Let's say you have an out-of-tree kernel module, like the one from the modules_out_of_tree.exp testcase. If you refer to the full pathname of the module, things work correctly: # stap -l 'module("/root/module/stap_modules_out_of_tree.ko").function("*_init")' module("/root/module/stap_modules_out_of_tree.ko").function("stap_modules_out_of_tree_init@/root/module/stap_modules_out_of_tree.c:8") However, a relative path doesn't work: # pwd /root/module # stap -l 'module("./stap_modules_out_of_tree.ko").function("*_init")'
Here's another oddity reported by Nan Xiao in <https://sourceware.org/ml/systemtap/2015-q4/msg00152.html>: ==== Another interesting thing: if there is a "-" in path, the SystemTap also fail to parse: # stap -v -l 'module("/root/Downloads/kernel-master/105.ops/kex.ko").function("*")' Pass 1: parsed user script and 102 library script(s) using 78528virt/28740res/2700shr/26724data kb, in 170usr/20sys/183real ms. Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 79536virt/30480res/3164shr/27732data kb, in 0usr/50sys/53real ms. Change kernel-master to kernel: # stap -v -l 'module("/root/Downloads/kernel/105.ops/kex.ko").function("*")' Pass 1: parsed user script and 102 library script(s) using 78528virt/28732res/2700shr/26724data kb, in 180usr/10sys/189real ms. module("/root/Downloads/kernel/105.ops/kex.ko").function("_open@/root/Downloads/kernel-master/105.ops/kex.c:21") module("/root/Downloads/kernel/105.ops/kex.ko").function("_read@/root/Downloads/kernel-master/105.ops/kex.c:45") module("/root/Downloads/kernel/105.ops/kex.ko").function("_release@/root/Downloads/kernel-master/105.ops/kex.c:33") module("/root/Downloads/kernel/105.ops/kex.ko").function("copy_to_user@/usr/src/linux-3.12.49-6/arch/x86/include/asm/uaccess_64.h:72") module("/root/Downloads/kernel/105.ops/kex.ko").function("kex_cleanup@/root/Downloads/kernel-master/105.ops/kex.c:90") module("/root/Downloads/kernel/105.ops/kex.ko").function("kex_init@/root/Downloads/kernel-master/105.ops/kex.c:61") Pass 2: analyzed script: 6 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 79548virt/30624res/3304shr/27744data kb, in 20usr/30sys/56real ms. ====
Looks like the "dash" problem mentioned in comment #1 comes from the following code from dwarf_builder::build() in tapsets.cxx: =============== else if (get_param (parameters, TOK_MODULE, module_name)) { // If not a full path was given, then it's an in-tree module. Replace any // dashes with underscores. if (!is_fully_resolved(module_name, sess.sysroot, sess.sysenv)) { size_t dash_pos = 0; string module_name2 = module_name; // copy out for replace operations while((dash_pos=module_name2.find('-'))!=string::npos) module_name2.replace(int(dash_pos),1,"_"); module_name = module_name2; filled_parameters[TOK_MODULE] = new literal_string(module_name); } // NB: glob patterns get expanded later, during the offline // elfutils module listing. dw = get_kern_dw(sess, module_name); } =============== The code is replacing *all* the dashes with underscores, not just the ones in the module file name itself.
Fixed in commit 51f0b23.