Summary: | Running a stap script throws up compilation error | ||
---|---|---|---|
Product: | systemtap | Reporter: | Mahesh J Salgaonkar <mahesh> |
Component: | translator | Assignee: | Unassigned <systemtap> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Mahesh J Salgaonkar
2009-01-13 10:30:55 UTC
Simliar problem reported at. http://sources.redhat.com/ml/systemtap/2009-q1/msg00031.html Could you please provide git-log |head -n 5 to tell us your stap tree status so that we can know the problem is still there or need to update your stap tree? (In reply to comment #1) > Could you please provide git-log |head -n 5 to tell us your > stap tree status so that we can know the problem is still there or > need to update your stap tree? > [salgaonkarm@mars systemtap]$ git-log | head -n 5 commit aa5951be9f4f12139cdcec4a501754a62b88c28b Author: Will Cohen <wcohen@peloton.usersys.redhat.com> Date: Thu Jan 8 14:28:15 2009 -0500 Check for xmlto that generates pdf. [salgaonkarm@mars systemtap]$ Please pull the commit http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=commit;h=dc38c256fac058289cdebd0fde881b4faf24b9d1 Or update to latest source to try again. > SystemTap translator/driver (version 0.8/0.138 git branch master, commit aa5951be) > [salgaonkarm@mars systemtap]$ sudo ./stap -k -vv -e 'probe > kernel.function("do_settimeofday"){printf("%u\n",$xtime->tv_sec)}' Wenji's recent changes should not affect this. > /tmp/stapu0EBq0/stap_16672.c:144: > s0 = ({ static unsigned long addr = 0; if (addr==0) addr = _stp_module_relocate > ("kernel","_stext",0xffffffff400f6618); addr; }); It's strange that this address should become associated with $xtime. Could you run with "--vp 02" and/or check the symbol table for the actual address of xtime? We may have some uninitialized memory, or a weird sign extension bug somewhere. I did some tests on x86. They all works fine, not only stap tree d294a64913b810cbe067655e06ea46a0184f99dc but also stap tree aa5951be9f4f12139cdcec4a501754a62b88c28b Seems the problem is specific to ppc. (In reply to comment #4) > It's strange that this address should become associated with $xtime. > Could you run with "--vp 02" and/or check the symbol table for the > actual address of xtime? We may have some uninitialized memory, or > a weird sign extension bug somewhere. > Applied commit dc38c256fac058289cdebd0fde881b4faf24b9d1 but problem still exist [salgaonkarm@mars systemtap]$ ./stap -V SystemTap translator/driver (version 0.8/0.138 git branch (no branch), commit dc38c256) Copyright (C) 2005-2008 Red Hat, Inc. and others This is free software; see the source for copying conditions. [salgaonkarm@mars systemtap]$ git-log | head -n 5 commit dc38c256fac058289cdebd0fde881b4faf24b9d1 Author: Wenji Huang <wenji.huang@oracle.com> Date: Sun Jan 11 18:39:55 2009 -0500 Fix compilation warning of too large number on 32-bits machines. [salgaonkarm@mars systemtap]$ sudo ./stap -k --vp 02 -e 'probe kernel.function("do_settimeofday"){printf("%u\n",$xtime->tv_sec)}' probe do_settimeofday@kernel/time/timekeeping.c:131 kernel reloc=.dynamic section=.text pc=0xc0443208 Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) in 300usr/270sys/565real ms. Pass 4: compilation failed. Try again with another '--vp 0001' option. Keeping temporary directory "/tmp/stapGQ3Y7B" [salgaonkarm@mars systemtap]$ sudo ./stap -k --vp 02 --vp 0001 -e 'probe kernel.function("do_settimeofday"){printf("%u\n",$xtime->tv_sec)}' probe do_settimeofday@kernel/time/timekeeping.c:131 kernel reloc=.dynamic section=.text pc=0xc0443208 Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) in 300usr/270sys/563real ms. Pass 4: compiled C into "stap_8597.ko" in 1750usr/390sys/2287real ms. Pass 4: compilation failed. Try again with another '--vp 0001' option. Keeping temporary directory "/tmp/stapyrwBpN" [salgaonkarm@mars systemtap]$ cat /proc/kallsyms | grep xtimecat /proc/kallsyms | grep xtimecat /proc/kallsyms | grep xtime [salgaonkarm@mars systemtap]$ cat /proc/kallsyms | grep xtime c04426ec T update_xtime_cache c0803c00 D xtime_lock c080f17c D inet_peer_gc_maxtime c08f7700 B xtime c08f7720 b xtime_cache [salgaonkarm@mars systemtap]$ cat /proc/kallsyms | grep do_settimeofday c0443208 T do_settimeofday c07b66c0 r __ksymtab_do_settimeofday c07c039c r __kstrtab_do_settimeofday [salgaonkarm@mars systemtap]$ (In reply to comment #5) > I did some tests on x86. They all works fine, not only > stap tree d294a64913b810cbe067655e06ea46a0184f99dc > but also > stap tree aa5951be9f4f12139cdcec4a501754a62b88c28b > Seems the problem is specific to ppc. But, I am seeing this issue on x86. My systems is x86 with F10 installed. [salgaonkarm@mars systemtap]$ uname -a Linux mars.in.ibm.com 2.6.27.9-159.fc10.i686 #1 SMP Tue Dec 16 15:12:04 EST 2008 i686 i686 i386 GNU/Linux [salgaonkarm@mars systemtap]$ cat /etc/redhat-release Fedora release 10 (Cambridge) [salgaonkarm@mars systemtap]$ > /tmp/stapu0EBq0/stap_16672.c:144:
> s0 = ({ static unsigned long addr = 0; if (addr==0) addr = _stp_module_relocate
> ("kernel","_stext",0xffffffff400f6618); addr; });
The above line is genarated by tapsets.cxx:1647, The statement reads as:
obstack_printf (pool, "if (addr==0) addr = _stp_module_relocate
(\"%s\",\"%s\",%#" PRIx64 "); ", modname, secname, address);
The variable 'address' is of type Dwarf_Addr which in turn of type unint64_t
Investigating how %#" PRIx64 " works on 32 bit platfrom. Comments are welcome.
(In reply to comment #7) > (In reply to comment #5) > > I did some tests on x86. They all works fine, not only > > stap tree d294a64913b810cbe067655e06ea46a0184f99dc > > but also > > stap tree aa5951be9f4f12139cdcec4a501754a62b88c28b > > Seems the problem is specific to ppc. > > But, I am seeing this issue on x86. My systems is x86 with F10 installed. Strange that I couldn't reproduce it on my F10. [wjhuang@localhost systemtap]$ uname -r 2.6.27.9-159.fc10.i686 [wjhuang@localhost systemtap]$ cat /etc/redhat-release Fedora release 10 (Cambridge) [wjhuang@localhost systemtap]$ sudo ./stap -ve 'probe kernel.function("do_settimeofday"){printf("%u\n",$xtime->tv_sec)}' Pass 1: parsed user script and 47 library script(s) in 230usr/20sys/264real ms. Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) in 1120usr/2270sys/4810real ms. Pass 3: translated to C into "/tmp/stapLF1DV9/stap_bc3e8911137ace8b71d347a1bbdc04e2_939.c" in 2120usr/4390sys/7918real ms. Pass 4: compiled C into "stap_bc3e8911137ace8b71d347a1bbdc04e2_939.ko" in 13290usr/5050sys/22142real ms. Pass 5: starting run. ^CPass 5: run completed in 10usr/130sys/8939real ms. [wjhuang@localhost systemtap]$ ./stap -V SystemTap translator/driver (version 0.8/0.137 git branch master, commit d294a649) Copyright (C) 2005-2008 Red Hat, Inc. and others This is free software; see the source for copying conditions. Seems the obvious difference is the version of elfutlils. Could be a bug of elfutils-0.138 ? > Seems the obvious difference is the version of elfutlils.
> Could be a bug of elfutils-0.138 ?
Good observation. And indeed, it worked for me with elfutils 0.137, but after
upgrading to 0.138 it now fails.
For Fedora 10 elfutils 0.138 is in updates-testing:
$ sudo yum --enablerepo=updates-testing upgrade elfutils-devel
Currently Systemtap 1.0/elfutils 0.142 this fails with: probe do_settimeofday@kernel/time/timekeeping.c:143 kernel reloc=.dynamic pc=0xffffffff8107994d semantic error: failed to retrieve location attribute for local 'xtime' (dieoffset: 0x7e5f28): identifier '$xtime' at <input>:1:56 source: probe kernel.function("do_settimeofday"){printf("%u\n",$xtime->tv_sec)} So I think this really is a duplicate of bug #10622. Please check if this is still happening. Fixes related to this were merged in release-1.1 and beyond. believed fixed |