[salgaonkarm@mars systemtap]$ ./stap -V SystemTap translator/driver (version 0.8/0.138 git branch master, commit aa5951be) Copyright (C) 2005-2008 Red Hat, Inc. and others This is free software; see the source for copying conditions. [salgaonkarm@mars systemtap]$ sudo ./stap -k -vv -e 'probe kernel.function("do_settimeofday"){printf("%u\n",$xtime->tv_sec)}' SystemTap translator/driver (version 0.8/0.138 git branch master, commit aa5951be) Copyright (C) 2005-2008 Red Hat, Inc. and others This is free software; see the source for copying conditions. Session arch: i686 release: 2.6.27.9-159.fc10.i686 Created temporary directory "/tmp/stapu0EBq0" Searched '/usr/local/share/systemtap/tapset/i686/*.stp', found 2 Searched '/usr/local/share/systemtap/tapset/*.stp', found 45 Pass 1: parsed user script and 47 library script(s) in 230usr/0sys/259real ms. 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 290usr/280sys/566real ms. probe_1383 locks nothing dump_unwindsyms kernel index=0 base=0xc0400000 Found build-id in kernel, length 20, end at 0xc06acbbc Pass 3: translated to C into "/tmp/stapu0EBq0/stap_16672.c" in 290usr/380sys/680real ms. Running make -C "/lib/modules/2.6.27.9-159.fc10.i686/build" M="/tmp/stapu0EBq0" modules >/dev/null cc1: warnings being treated as errors /tmp/stapu0EBq0/stap_16672.c: In function ‘function__dwarf_tvar_get_xtime_0’: /tmp/stapu0EBq0/stap_16672.c:144: error: integer constant is too large for ‘long’ type /tmp/stapu0EBq0/stap_16672.c:144: error: large integer implicitly truncated to unsigned type make[1]: *** [/tmp/stapu0EBq0/stap_16672.o] Error 1 make: *** [_module_/tmp/stapu0EBq0] Error 2 Pass 4: compiled C into "stap_16672.ko" in 1670usr/360sys/2301real ms. Pass 4: compilation failed. Try again with another '--vp 0001' option. Keeping temporary directory "/tmp/stapu0EBq0" [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 script works fine on ppc64. Looks like problem occurs only on 32 bit platform.
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