Description of problem: I get the following compilation error when runing compiling a stap script: /usr/share/systemtap/runtime/regs.c: In function '_stp_ret_addr': /usr/share/systemtap/runtime/regs.c:49: error: 'struct pt_regs' has no member named 'esp' /usr/share/systemtap/runtime/regs.c: In function '_stp_print_regs': /usr/share/systemtap/runtime/regs.c:235: error: 'struct pt_regs' has no member named 'eip' /usr/share/systemtap/runtime/regs.c:236: error: 'struct pt_regs' has no member named 'esp' /usr/share/systemtap/runtime/regs.c:238: error: 'struct pt_regs' has no member named 'eax' /usr/share/systemtap/runtime/regs.c:238: error: 'struct pt_regs' has no member named 'ebx' /usr/share/systemtap/runtime/regs.c:238: error: 'struct pt_regs' has no member named 'ecx' /usr/share/systemtap/runtime/regs.c:238: error: 'struct pt_regs' has no member named 'edx' /usr/share/systemtap/runtime/regs.c:240: error: 'struct pt_regs' has no member named 'esi' /usr/share/systemtap/runtime/regs.c:240: error: 'struct pt_regs' has no member named 'edi' /usr/share/systemtap/runtime/regs.c:240: error: 'struct pt_regs' has no member named 'ebp' /usr/share/systemtap/runtime/regs.c:242: error: 'struct pt_regs' has no member named 'xds' /usr/share/systemtap/runtime/regs.c:242: error: 'struct pt_regs' has no member named 'xes' Version-Release number of selected component (if applicable): systemtap-0.6.1-4.fc9.i386 kernel-2.6.25-0.46.rc1.git2.fc8.i686 How reproducible: everytime Steps to Reproduce: 1.stap -gvv top-nfscalls.stp
I didn't see kernel-2.6.25-0.46.rc1.git2.fc8.i686 in koji. Where did that kernel come from? Is it a locally built kernel? If so, what was the config file for it. Also include the top-nfscall.stp script.
It was a kernel I built out of the fedora cvs tree (cvs.fedora.redhat.com:/cvs/pkgs). The steps I used were cvs co kernel/devel cd kernel; cvs co common cd devel; make test-srpm rpm -ihv kernel*.rpm cd /usr/src/redhat/SPECS rpmbuild -bb --with baseonly --without modsign --target i686 kernel.spec
Created attachment 295619 [details] top-nfscalls.stp
Confirmed with rawhide kernel and 0.6.1-4.fc9 systemtap. CVS systemtap works fine in that the modules build, but something else is messing up and the probes are not actually getting found. BTW, the appropriate idiom for the kernel|module thing is kernel.function(....) ! , module("nfs").function(....) { } That is essentially an XOR, and will cause a translation failure if NEITHER is found for some reason.
Actually CVS systemtap works fine. __fswab32 sure gets run a lot. (I had an i586-vs-686 screwup on my rawhide kernel virtual machine, now fixed.) Another performance suggestion: replace the "++" with "<<< 1", and then in the loop printf ... @count(nfscalls[name]).
Comment on attachment 295619 [details] top-nfscalls.stp #!/usr/bin/env stap global nfscalls probe begin { printf("Collecting data...\n") } probe kernel.function("*@fs/nfs") !, module("nfs").function("*@fs/nfs/*") { nfscalls[probefunc()]<<<1 } probe end { foreach (name in nfscalls- limit 20) printf("%10d %s\n", @count(nfscalls[name]), name) }
Created attachment 295708 [details] output of stap -gvv command hmm... I'm still seen the computation error with kernel-2.6.25-0.64.rc2.git5.fc8.i686 and systemtap-0.6.1-4.fc9.i386 and systemtap-runtime-0.6.1-4.fc9.i38 The script I'm using has two lines: #cat nfs.stp probe begin { log("starting NFS probe") } probe end { log("ending NFS probe") } The command I'm using is: stap -gvv nfs.stp Attached it the output of that command. Which version of systemtap are you using?
> Which version of systemtap are you using? One built fresh out of CVS.
It seems that a series of patches committed to systemtap's runtime on or near 2008-01-24, sadly not documented by ChangeLog entries, is responsible for this. Start hunting from src/buildrun.cxx: 1.47 (srinivas 18-Jan-08): o << module_cflags << " += $(call stap_check_build, $ (SYSTEMTAP_RUNTIME)/autoconf-x86-uniregs.c, -DSTAPCONF_X86_UNIREGS,)" << endl; 1.47 (srinivas 18-Jan-08): 1.47 (srinivas 18-Jan-08): o << module_cflags << " += $(call stap_check_build, $ (SYSTEMTAP_RUNTIME)/autoconf-nameidata.c, -DSTAPCONF_NAMEIDATA_CLEANUP,)" << endl;
(In reply to comment #9) > It seems that a series of patches committed to systemtap's runtime > on or near 2008-01-24, sadly not documented by ChangeLog entries, > is responsible for this. Start hunting from src/buildrun.cxx: > Frank Iam sorry, It was my mistake. I will update the changelog. Patches that I have committed to solve this problem are listed below. Please let me know if you need any help. http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=commit;h=c7bcf4514f821aafb8540ebe60f308c0bad1f2b6 http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=history;f=runtime/autoconf-x86-uniregs.c;h=25729c220a2468a430929b3b428b1be980454fa2;hb=HEAD http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=history;f=runtime/autoconf-nameidata.c;h=c1d02400dcd97af13275cd6b58e69e68780e0dec;hb=HEAD
Created attachment 296253 [details] makes errno.stp work with kernels with unified 32-bit and 64-bit reg names Found could also replicate the problem with systemtap's src/examples/small_demos/close.stp. Looking through the code I found that tapset/errno.stp didn't handle the case where newer kernel using the unified names for 32-bit and 64-bit kernels. The proposed patch has been tested on 32-bit machine running 2.6.25-0.61.rc2.git4.fc9PAE kernel and appeared to resolve the problem.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The systemtap-0.6.2-1.fc9 build appears to work fine.