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

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

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14436

             Bug #: 14436
           Summary: warn about use of $vars (e.g. in return probes) with
                    unoptimized object code with poor VTA
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: fche@redhat.com
    Classification: Unclassified


gcc is well-known not to perform proper VTA analysis for object code that is
built with -g but without -O2.  That means that gcc lies as to the
liveness/location of e.g. local variables.


% 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("./t").function("frob").return { 
    printf("a=%d\nx=%d\nr=%d\n", @defined($a)?$a:-1, @entry($x), $return) 
}
% gcc -g t.c -o t
% stap t.stp -c ./t
... results in a bad/garbage value for $a and/or $x
% gcc -O2 -fno-inline t.c -o t
% stap t.stp -c ./t
... results in a properly-missing value for $a, and correct values for others

Systemtap should start looking for the DW_TAG_compile_unit / DW_AT_producer
string to see if -g -O* were used together with a modern gcc (yey for working
VTA), and warn otherwise (boohoo for non-working VTA).


PS:  Note prologue checking was done, and could have resulted in a plausible
probe address adjustment to make it work despite non-VTA.  But, due to this
being a .return probe, prologue searching results were duly disposed-of:

searching for prologue of function 'frob'
0x4004c4-0x4004dc@/home/fche/tmp/kkk/t.c:4
checking line record 0x4004c4@/home/fche/tmp/kkk/t.c:4
checking line record 0x4004cb@/home/fche/tmp/kkk/t.c:5
prologue found function 'frob' = 0x4004cb
ignoring prologue for .return probes

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

[mjw at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14436

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> 2012-08-06 12:50:35 UTC ---
Also note the (KFAILed) testcase in
http://sourceware.org/bugzilla/show_bug.cgi?id=13420 which is probably related.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[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
----------------------------------------------------------------------------
                 CC|                            |jlebon at redhat dot com

-- 
You are receiving this mail because:
You are the assignee for the bug.

[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.