http://permalink.gmane.org/gmane.linux.systemtap hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.systemtap/20779 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=15638 --- Comment #3 from niku &lt;vaibhav.niku at yandex dot com&gt; --- Same problem with: http:// sources.redhat.com/git/?p=systemtap.git;a=blob_plain;f=README;hb=HEAD I think sourceware.org is the culprit; it is supposed to decode the GET string, but it isn't doing that. If that is so, all links on the Systemtap wiki containing special characters will fail. </pre> vaibhav.niku at yandex dot com 2013-06-19T05:21:42 http://permalink.gmane.org/gmane.linux.systemtap/20778 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=15638 --- Comment #2 from niku &lt;vaibhav.niku at yandex dot com&gt; --- So the error isn't bizarre, but vanilla. I hadn't noticed the Host: field. </pre> vaibhav.niku at yandex dot com 2013-06-19T04:58:16 http://permalink.gmane.org/gmane.linux.systemtap/20777 <pre>Hi David, Thank you very much for going through my input and providing an excellent answer. Your input nailed it for me (although with a twist; see below) On 06/17/2013 08:16 PM, David Smith wrote: OK, thanks, will remove it later... Kept it for now: better safe than sorry. My problem turned out to be environment variables indeed! Thank you for pointing me in this direction. However, the culprit was that LD_LIBRARY_PATH got killed. Simply adding env LD_LIBRARY_PATH=... to the staprun solved the problem: http://sourceforge.net/p/kaarpux/code/ci/master/tree/master/shinc/linux_functions.shinc So, again: THANKS A MILLION FOR THE HINT !!! /Henrik </pre> Henrik /KaarPoSoft 2013-06-18T20:20:03 http://permalink.gmane.org/gmane.linux.systemtap/20776 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=15638 Frank Ch. Eigler &lt;fche at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fche at redhat dot com --- Comment #1 from Frank Ch. Eigler &lt;fche at redhat dot com&gt; --- This problem was reported to the sysadmins maintaining the sources.redhat.com http-forwarding machine. In the mean time, we could fix the wiki to point at http://sourceware.org/ </pre> fche at redhat dot com 2013-06-18T19:57:27 http://permalink.gmane.org/gmane.linux.systemtap/20775 <pre>Hi, On 06/17/2013 08:05 PM, Mark Wielaard wrote: ah ok thanks so it's currently unsupported. Ok thanks for pointing out. If someone has a first ppc32.h file and needs some help for testing on a native 32 bit ppc system, let me know. Or maybe in the next week I find the time to implement one. Best regards Holger </pre> Holger Brunck 2013-06-18T07:00:58 http://permalink.gmane.org/gmane.linux.systemtap/20774 <pre>Hi Mark, On 06/17/2013 07:43 PM, Mark Wielaard wrote: no it's not a 32 Bit program running on a 64bit machine it's a 32 bit ppc binary crosscompiled on a 64 bit x86 architecture. The target architecture is a 32 bit ppc. Best regards Holger </pre> Holger Brunck 2013-06-18T06:46:18 http://permalink.gmane.org/gmane.linux.systemtap/20773 <pre> Thanks, the patch looks very good! I have just a few comments. Too bad about cu_name -- perhaps that's a cleanup for another day. I do have a few suggestions for that though. If these are really needed, they should go in testsuite/.gitignore. But generally, most of our testcases clean up after themselves. Some tests leave the files around in verbose mode, which is fine. It seems inflexible to me that get_cu_scope() is trying to find just one best-matching CU, which is the only one that will get searched for the variable. I think it would be better to try *all* CUs that look like a match. This should be pretty easy by pushing the code generation into a deeper loop through dw.iterate_over_cus. Take a look at how tracepoint_query_cu() is used, for example. That one doesn't care about the actual cu_name, but that's easy enough to add for &lt; at &gt;var. Consider also that we could allow &lt; at &gt;var("foo", "module"), having no cu_name specified by the user, so it would iterate over them all. This is a hint to me</pre> Josh Stone 2013-06-18T01:06:28 http://permalink.gmane.org/gmane.linux.systemtap/20772 <pre>Hi Frank, Do u agree or disagree with my analysis? On Fri, Jun 14, 2013 at 10:13 AM, Jia He &lt;hejianet&lt; at &gt;gmail.com&gt; wrote: </pre> Jia He 2013-06-18T00:31:43 http://permalink.gmane.org/gmane.linux.systemtap/20771 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=11421 David Smith &lt;dsmith at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED CC| |dsmith at redhat dot com Resolution|--- |INVALID --- Comment #5 from David Smith &lt;dsmith at redhat dot com&gt; --- Since this bug has been "waiting" for over three years, and current versions of systemtap work correctly here, I'm closing this one. </pre> dsmith at redhat dot com 2013-06-17T20:52:36 http://permalink.gmane.org/gmane.linux.systemtap/20770 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=11414 David Smith &lt;dsmith at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dsmith at redhat dot com Resolution|--- |FIXED --- Comment #4 from David Smith &lt;dsmith at redhat dot com&gt; --- With bug #11424 fixed, the nd_syscall.exp testcase passes like the syscall.exp testcase (but see bug #15219). Here's the output I got on 3.10.0-0.rc5.git0.1.fc20.x86_64: ==== Running ../../src/testsuite/systemtap.syscall/nd_syscall.exp ... FAIL: 32-bit clock nd_syscall FAIL: 32-bit sendfile nd_syscall FAIL: 32-bit timer nd_syscall FAIL: 32-bit trunc nd_syscall === systemtap Summary === # of expected passes 66 # of unexpected failures 4 # of unsupported tests 1 ==== </pre> dsmith at redhat dot com 2013-06-17T20:49:51 http://permalink.gmane.org/gmane.linux.systemtap/20769 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=15625 Dave Brolley &lt;brolley at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|systemtap at sourceware dot org |brolley at redhat dot com </pre> brolley at redhat dot com 2013-06-17T19:20:31 http://permalink.gmane.org/gmane.linux.systemtap/20768 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=15625 Dave Brolley &lt;brolley at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brolley at redhat dot com --- Comment #4 from Dave Brolley &lt;brolley at redhat dot com&gt; --- (In reply to Jim Keniston from comment #1) The proper and more general solution for this is to fix embeddedc.awk so that it does not analyse stub functions. Skipping entire files is too granular. </pre> brolley at redhat dot com 2013-06-17T19:19:59 http://permalink.gmane.org/gmane.linux.systemtap/20767 <pre>Colleagues, my co-worker Jim Baxter and I have been trying to get cross-compiled SystemTap scripts to work with modules on Freescale ARMv7 i.MX6. First I compiled and ran several examples on the target board from http://sourceware.org/systemtap/examples/ just to make sure that the whole machinery was working. The compilation host is an Ubuntu VM. My goal involves probing modules, so next I tried compiling the file probedrm.stp probe module("drm").function("*") {print("I am here\n"); exit();} using the following script --- STAP_SYSROOT="/build/meibp-2013/build/tmp/sysroots" CROSS_COMPILE=arm-none-linux-gnueabi- STP_FILE=probedrm.stp STP_BASE_NAME=$(basename ${STP_FILE} .stp) ${STAP_SYSROOT}/x86_64-linux/usr/bin/stap $1 -a arm -v -g \ -R ${STAP_SYSROOT}/mx6q/usr/share/systemtap/runtime \ --sysroot=${STAP_SYSROOT}/mx6q \ -B CROSS_COMPILE=${CROSS_COMPILE} \ -r ${STAP_SYSROOT}/mx6q/usr/src/kernel \ ${STP_FILE} -d</pre> Chaiken, Alison 2013-06-17T18:33:14 http://permalink.gmane.org/gmane.linux.systemtap/20766 <pre> The script looks reasonable. One small note, you shouldn't need the '&lt; at &gt;defined($return)' check since $return should always be defined in 'kernel.function("do_filp_open").return'. ... Here's my thought. I don't think it is the probe itself that is causing the problem, my guess would be that it is our staprun loader (a setuid executable). When the module gets loaded, we unset several environment variables, like 'IFS', 'CDPATH', 'ENV', 'BASH_ENV' for security reasons. I'd guess those failing packages depend on something set in the environment. If this is the case, to work around this problem you might be able to modify the script you use to run staprun (linux_functions.shinc) to add the environment variable back in. Here's that line from linux_functions.shinc (split up a bit): ==== staprun /lib/modules/$(uname -r)/systemtap/kx_open.ko \ -c "./scripts/${PASS}/${PKG}_${STEP}.sh" \ -o "${PIPE}" &gt; ./log/${PASS}/${PKG}_${STEP}.log 2&gt;&amp;1 ==== You could change that to ==== staprun /lib/modules/$(uname -r</pre> David Smith 2013-06-17T18:16:15 http://permalink.gmane.org/gmane.linux.systemtap/20765 <pre> Yeah thanks. I had completely forgotten I only implemented the DWARF unwinder for ppc64. Sorry. This was because when I wrote the powerpc DWARF unwinder (kernel support) I only had access to ppc64 kernels. So for a ppc32 kernel we do need a new runtime/unwind/ppc32.h definitions file. It should not be that hard to write based on the ppc64.h version and the ppc32 DWARF register mappings from http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf But note that testing might be needed to see if those really map to actually used DWARF register numbers generated by the toolchain. As can be seen in the comments in ppc64.h sometimes mistakes have been made and theory/spec and practice are not the same :{ Cheers, Mark </pre> Mark Wielaard 2013-06-17T18:05:48 http://permalink.gmane.org/gmane.linux.systemtap/20764 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=10272 Lukas Berk &lt;lberk at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lberk at redhat dot com Assignee|systemtap at sourceware dot org |lberk at redhat dot com </pre> lberk at redhat dot com 2013-06-17T18:02:04 http://permalink.gmane.org/gmane.linux.systemtap/20763 <pre>Hey, Unfortunately I believe this is because we don't actually support powerpc32 (only ppc64.h is defined in unwind.h). So while the first error you're getting is being worked on (I'm currently working on PR10272[1] so hopefully it'll be resloved soon), the second error will be the show stopper here. Thanks, Lukas [1] - http://sourceware.org/bugzilla/show_bug.cgi?id=10272 </pre> Lukas Berk 2013-06-17T18:00:09 http://permalink.gmane.org/gmane.linux.systemtap/20762 <pre> It looks like ppc64 is supported, at least according to runtime/linux/runtime.h. If 'powerpc64' is defined, STP_USE_DWARF_UNWINDER gets defined. Does getting a backtrace for a simple 64-bit program work? I've CC'ed Mark Wielaard, who might know off the top of his head what the status of getting a 32-bit backtrace on ppc64 is. </pre> David Smith 2013-06-17T17:46:11 http://permalink.gmane.org/gmane.linux.systemtap/20761 <pre> Yes, if your powerpc kernel is 64bit, but the user program is 32bit (same for 32bit user space on x86_64) then you will get that warning during stap translation time (the stap script should still run, but won't produce a user backtrace for the 32bit module/library/process). This is bug: http://sourceware.org/bugzilla/show_bug.cgi?id=10272 "backtraces fail with 32-on-64 executables" This might be caused by the cross compiling, maybe something got confused about the architecture. You get that when: #ifndef STP_USE_DWARF_UNWINDER powerpc (and x86_64) both should use the DWARF_UNWINDER. So you might want to look at why that doesn't get defined in your case. Cheers, Mark </pre> Mark Wielaard 2013-06-17T17:43:34 http://permalink.gmane.org/gmane.linux.systemtap/20760 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=15638 niku &lt;vaibhav.niku at yandex dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor </pre> vaibhav.niku at yandex dot com 2013-06-17T16:55:18 http://permalink.gmane.org/gmane.linux.systemtap/20759 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=15638 Bug ID: 15638 Summary: a link on sourceware.org/systemtap site behaving in a strange manner Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: documentation Assignee: systemtap at sourceware dot org Reporter: vaibhav.niku at yandex dot com Created attachment 7080 --&gt; http://sourceware.org/bugzilla/attachment.cgi?id=7080&amp;action=edit log of 3 three streams The given link† on the webpage is behaving in a bizarre manner. Check the TCP streams 1 and 3 in the attached page. The request is _identical_, but the HTTP server responds in two different _reproducible_ ways: once resulting in a 404 error, and once serving the correct page. †http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=blob_plain;f=INTERNALS;hb=HEAD To reproduce: (i) Go to http://sourceware.org/systemtap/wiki/Sys</pre> vaibhav.niku at yandex dot com 2013-06-17T16:51:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.systemtap