This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/14436] warn about use of $vars (e.g. in return probes) with unoptimized object code with poor VTA
- From: "jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 04 Mar 2014 21:56:09 +0000
- Subject: [Bug translator/14436] warn about use of $vars (e.g. in return probes) with unoptimized object code with poor VTA
- Auto-submitted: auto-generated
- References: <bug-14436-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14436
Jonathan Lebon <jlebon at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Jonathan Lebon <jlebon at redhat dot com> ---
Commit 5a617dc addresses these issues. Notably, prologue-searching results are
no longer discarded:
PR14436: fix target vars for process.function.return probes
Because uretprobes rely on modifying the stack in order to catch
returns, they always had to be placed at the function's entrypc, which
meant that prologue searching could not be performed (see also PR13200).
This patch re-enables prologue searching for .return probes if necessary
(i.e. if code is unoptimized). The uretprobe remains at the entrypc, but
target variables are expanded at the prologue end and the paired entry
probe is also placed there rather than at the entrypc.
In practice, this means that the example in comment 0 now works:
$ cat t.c
#include <stdio.h>
static int frob(int x) {
int a = 42;
return a + x;
}
int main(void)
{
printf("%d\n", frob(42));
return 0;
}
$ cat t.stp
probe process.function("frob").return {
printf("a=%d\nx=%d\nr=%d\n", @defined($a)?$a:-1, $x, $return)
}
$ gcc -g t.c -o t
$ stap t.stp -c ./t
84
a=0
x=42
r=84
$
i.e. we get a proper value for $x. On the other hand, $a is not initialized yet
at this point, so shows up as 0. This is in line with what we say in
stapprobes(3stap):
For ".return" probes, context variables other than the "$return"
may be accessible, as a convenience for a script programmer wishing
to access function parameters. These values are snapshots taken at
the time of function entry. Local variables within the function
are not generally accessible, since those variables did not exist
in allocated/initialized form at the snapshot moment.
--
You are receiving this mail because:
You are the assignee for the bug.