see src/testsuite/buildok/six.stp. stap currently fails to resolve the inlined copies of "context_switch", which btw could occur not just in the kernel but in modules too.
we are now resolving the function itself (try changing the probe body to just print a constant string); what we fail to do is resolve the location of the target variables rerpresenting the inline's parameters. this is due to gcc not generating the correct dwarf information; it will not be fixed in the immediate timeframe. this is filed as gcc bug "debug/23551"; pinskia reports that such cases either result in the inline being completely elided by the optimizer (no location to probe) or else a known bug which was fixed in gcc 4.1. we will have to re-investigate when we have kernels built with 4.1.
We too have a customer who wants to instrument context_switch. Looks like gcc 4.1 is out now. A status update at your earliest convenience would be appreciated.
A systemtap user reported continued inline problems, in a kernel compiled with gcc 4.1. Test case again 2.6.16rc3: probe kernel.statement("*@kernel/timer.c:464") { printf("%p:%p\n", $fn, $data); }
I tried i386/gcc 4.1.1/FC5 and ppc64/gcc 3.4.5/RHEL4 with latest SystemTap/elfutils, both failed to resove the target symbol. On i386/gcc 4.1.1, GCC compiles away the loc info of all the arguments of context_switch(), so SystemTap failed to resolve the target symbol. On ppc64/gcc 3.4.5, although GCC only compiles away the loc info of $rq, but the loc info of $prev and $next exists. But when I tried to retrieve $prev/$next of context_switch(), SystemTap still failed to resolve them. I checked the gcc bug 23551, still not fixed. :-(
There is nothing which GCC can do better really as you want optimizations so we give you optimizations but you also want exact debugging info, you really cannot have both.
(In reply to comment #5) > There is nothing which GCC can do better really as you want optimizations so we > give you optimizations but you also want exact debugging info, you really cannot > have both. Andrew, that may be a true general impression, but this scenario deserves more detailed analysis.
We are blocked on <http://gcc.gnu.org/PR23551>.
Created attachment 1841 [details] Cannot find $task local variable for probe point On the 2.6.21-1.3142.fc7 x86_64 kernel the $task parameter of inline rpc_release_task() appears to prevent systemtap.samples/lket.stp from compiling. Get the following message: $ ../../install/bin/stap -v /tmp/rpc.stp Pass 1: parsed user script and 54 library script(s) in 1220usr/50sys/1278real ms. semantic error: failed to retrieve location attribute for local 'task' (dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:3:22 semantic error: failed to retrieve location attribute for local 'task' (dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:4:24 semantic error: failed to retrieve location attribute for local 'task' (dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:5:24 semantic error: failed to retrieve location attribute for local 'task' (dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:6:24 Pass 2: analyzed script: 1 probe(s), 4 function(s), 1 embed(s), 0 global(s) in 200usr/360sys/553real ms. Pass 2: analysis failed. Try again with more '-v' (verbose) options.
*** Bug 4510 has been marked as a duplicate of this bug. ***
What is this status? Since static functions which called from one place are compiled as an inline automatically(even if it is not obviously marked as "inline"), this feature is very important.
With aoliva's latest gcc var-tracking code, linux 2.6.27-rc2 was compilable, runnable, and showed some promise with respect to inline function parameters. For example, this started to work: probe kernel.function("context_switch") {println($next)} However, by printing "$$vars" instead, one can see that the other parameters are not visible at that place. Setting a statement probe a few lines down exposes $prev and a few more locals though, which is a good sign.
I believe the following new regressions under 2.6.26.3-29.fc9.x86_64 are also caused by this: Running /home/mark/src/systemtap/testsuite/systemtap.examples/check.exp ... FAIL: systemtap.examples/process/sig_by_pid build FAIL: systemtap.examples/process/sig_by_pid run FAIL: systemtap.examples/process/sig_by_proc build FAIL: systemtap.examples/process/sig_by_proc run FAIL: systemtap.examples/process/sigkill build FAIL: systemtap.examples/process/sigkill run FAIL: systemtap.examples/process/sigmon build FAIL: systemtap.examples/process/sigmon run They all fail in the same way: attempting command stap -p4 sig_by_pid.stp OUT semantic error: failed to retrieve location attribute for local 'sig' (dieof fset: 0x4bbda9): identifier '$sig' at /usr/local/systemtap/share/systemtap/tapse t/signal.stp:92:11 semantic error: failed to retrieve location attribute for local 't' (dieoffset: 0x4bbd9f): identifier '$t' at :93:12 semantic error: failed to retrieve location attribute for local 'sig' (dieoffset : 0x4bbeef): identifier '$sig' at :92:11 semantic error: failed to retrieve location attribute for local 't' (dieoffset: 0x4bbee5): identifier '$t' at :93:12 semantic error: failed to retrieve location attribute for local 'sig' (dieoffset : 0x4bd412): identifier '$sig' at :92:11 semantic error: failed to retrieve location attribute for local 't' (dieoffset: 0x4bd408): identifier '$t' at :93:12 semantic error: failed to retrieve location attribute for local 'sig' (dieoffset : 0x4bbda9): identifier '$sig' at :92:11 specific_send_sig_info used to be a larger static function in kernel/signal.c, but in 2.6.26 is just a simple oneliner: static int specific_send_sig_info(int sig, struct siginfo *info, struct task_struct *t) { return send_signal(sig, info, t, 0); }
I have created a bug 7030 as this can be solved by changing the signal.stp and not wait till the gcc inlining issue is solved. (In reply to comment #12) > Running /home/mark/src/systemtap/testsuite/systemtap.examples/check.exp ... > FAIL: systemtap.examples/process/sig_by_pid build > FAIL: systemtap.examples/process/sig_by_pid run > FAIL: systemtap.examples/process/sig_by_proc build > FAIL: systemtap.examples/process/sig_by_proc run > FAIL: systemtap.examples/process/sigkill build > FAIL: systemtap.examples/process/sigkill run > FAIL: systemtap.examples/process/sigmon build > FAIL: systemtap.examples/process/sigmon run >
With gcc 4.5 (and partial vta backports in RH gcc 4.4.*), this problem is more or less history.