[Bug translator/14436] warn about use of $vars (e.g. in return probes) with unoptimized object code with poor VTA

[jlebon at redhat dot com]

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.