Created attachment 813745 [details] Script for attaching gdb Description of problem: Hi. I have systemtap-2.4-0.137.gbbb71aa.fc21.x86_64 + kernel-3.12.0-0.rc5.git1.1.fc21.x86_64 installed on top of fedora 19. When I want compile my script (is attached), which uses procfs probes, this is what I've got from stap (below in Actual results section). Version-Release number of selected component (if applicable): kernel-3.12.0-0.rc5.git2.1.fc21.x86_64 systemtap-2.4-0.137.gbbb71aa.fc21.x86_64 kernel-devel-3.12.0-0.rc5.git2.1.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. # stap attach-gdb.stp Actual results: [root@gremlinka tmp]# stap attach-gdb.stp semantic error: while resolving probe point: identifier 'kernel' at /usr/share/systemtap/tapset/linux/kprocess.stp:58:5 source: kernel.function("do_execve"), ^ semantic error: missing x86_64 kernel/module debuginfo [man warning::debuginfo] under '/lib/modules/3.12.0-0.rc5.git2.1.fc21.x86_64/build' semantic error: while resolving probe point: identifier 'kprocess' at attach-gdb.stp:15:7 source: probe kprocess.exec { ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] Expected results: Working script. Additional info: When I remove procfs interface, everything works just fine.
On my system, I see the following error: ==== # stap -kv ../attach-gdb.stp Pass 1: parsed user script and 97 library script(s) using 211836virt/26968res/2868shr/24884data kb, in 170usr/40sys/212real ms. Pass 2: analyzed script: 6 probe(s), 7 function(s), 3 embed(s), 1 global(s) using 406944virt/67812res/4112shr/64040data kb, in 1230usr/240sys/1481real ms. Pass 3: translated to C into "/tmp/stapV0o2Xd/stap_3038_src.c" using 404464virt/70332res/6756shr/64040data kb, in 10usr/90sys/108real ms. In file included from /tmp/stapV0o2Xd/stap_3038_src.c:1323:0: /usr/local/share/systemtap/runtime/procfs.c: In function ‘_stp_mkdir_proc_module’: /usr/local/share/systemtap/runtime/procfs.c:127:2: error: implicit declaration of function ‘vfs_path_lookup’ [-Werror=implicit-function-declaration] rc = vfs_path_lookup(mnt->mnt_root, mnt, "systemtap", 0, &path); ^ cc1: all warnings being treated as errors make[1]: *** [/tmp/stapV0o2Xd/stap_3038_src.o] Error 1 make: *** [_module_/tmp/stapV0o2Xd] Error 2 WARNING: kbuild exited with status: 2 Pass 4: compiled C into "stap_3038.ko" in 7380usr/1500sys/8949real ms. Pass 4: compilation failed. [man error::pass4] Keeping temporary directory "/tmp/stapV0o2Xd" ==== So, we can't find the declaration of vfs_path_lookup(). The following kernel commit moved it to fs/internal.h: ==== commit 197df04c749a07616621b762e699b1fff4102fac Author: Al Viro <viro.org.uk> Date: Sun Sep 8 14:03:27 2013 -0400 rename user_path_umountat() to user_path_mountpoint_at() ... and move the extern from linux/namei.h to fs/internal.h, along with that of vfs_path_lookup(). Signed-off-by: Al Viro <viro.org.uk> ==== vfs_path_lookup() is still exported, but there is no longer a visible declaration. I'll have to do more digging here.
Fixed in upstream commit 33f0271. <http://www.sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=33f02716575ce506482441e1c722a86c7d3ffa20> This adds support for using kern_path() which is exported and has a visible declaration.
in recent releases