Bug 433780 - Compilation error in runtime/regs.c
Compilation error in runtime/regs.c
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: systemtap (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Frank Ch. Eigler
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-21 08:31 EST by Steve Dickson
Modified: 2008-06-10 12:55 EDT (History)
2 users (show)

See Also:
Fixed In Version: 0.6.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-10 12:55:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
top-nfscalls.stp (317 bytes, text/plain)
2008-02-22 07:08 EST, Steve Dickson
no flags Details
output of stap -gvv command (12.19 KB, text/plain)
2008-02-23 11:58 EST, Steve Dickson
no flags Details
makes errno.stp work with kernels with unified 32-bit and 64-bit reg names (648 bytes, patch)
2008-02-28 15:25 EST, William Cohen
no flags Details | Diff

  None (edit)
Description Steve Dickson 2008-02-21 08:31:32 EST
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
Comment 1 William Cohen 2008-02-21 09:54:19 EST
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.


Comment 2 Steve Dickson 2008-02-22 07:03:42 EST
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

Comment 3 Steve Dickson 2008-02-22 07:08:20 EST
Created attachment 295619 [details]
top-nfscalls.stp
Comment 4 Frank Ch. Eigler 2008-02-23 07:59:39 EST
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.
Comment 5 Frank Ch. Eigler 2008-02-23 08:48:35 EST
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 6 Frank Ch. Eigler 2008-02-23 10:14:35 EST
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)
}
Comment 7 Steve Dickson 2008-02-23 11:58:25 EST
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?
Comment 8 Frank Ch. Eigler 2008-02-23 16:13:19 EST
> Which version of systemtap are you using?

One built fresh out of CVS.
Comment 9 Frank Ch. Eigler 2008-02-23 16:32:19 EST
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;

Comment 10 Srinivasa Ds 2008-02-27 00:27:40 EST
(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
Comment 11 William Cohen 2008-02-28 15:25:50 EST
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.
Comment 12 Bug Zapper 2008-05-14 01:19:12 EDT
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
Comment 13 Frank Ch. Eigler 2008-06-10 12:55:10 EDT
The systemtap-0.6.2-1.fc9 build appears to work fine.

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