Bug 1020853 - stap is not able to compile script when procfs probe is used.
stap is not able to compile script when procfs probe is used.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: systemtap (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Smith
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-18 07:33 EDT by Robin Hack
Modified: 2014-04-06 20:56 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-06 20:56:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Script for attaching gdb (427 bytes, text/plain)
2013-10-18 07:33 EDT, Robin Hack
no flags Details

  None (edit)
Description Robin Hack 2013-10-18 07:33:53 EDT
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.
Comment 1 David Smith 2013-10-18 16:43:09 EDT
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@zeniv.linux.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@zeniv.linux.org.uk>                            
====

vfs_path_lookup() is still exported, but there is no longer a visible declaration. I'll have to do more digging here.
Comment 2 David Smith 2013-11-04 12:20:44 EST
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.
Comment 3 Frank Ch. Eigler 2014-04-06 20:56:38 EDT
in recent releases

Note You need to log in before you can comment on or make changes to this bug.