Take the following program foo.c: $ cat foo.c /* { dg-options "-g -O2" } */ extern void abort (void); volatile int v; #define V1 v++; v++; v++; v++; v++; v++; v++; v++; v++; v++; #define V2 V1 V1 V1 V1 V1 V1 V1 V1 V1 V1 static int foo (int x) { int a = 2 * x + 4; int b = 6; if (x < 30) { int c = 8; int d = 8 * x; return 6; } else { int e = 134; int f = 9 * x; V2 return v + 17; } } int main (void) { if (foo (v) > 10000) abort (); foo (70); return 0; } Compiled with gcc 4.5 -g -O2 -o foo.old foo.c systemtap is happy to probe the (inlined) foo and variables: $ stap -e 'probe process ("./foo.old").function("foo") { printf("%s@0x%x\n", pp(), uaddr()); log ($$vars) }' -c ./foo.old process("/tmp/foo.old").function("foo@/tmp/foo.c:8")@0x4004d0 x=0x0 a=0x4 b=0x6 process("/tmp/foo.old").function("foo@/tmp/foo.c:8")@0x4004d0 x=0x46 a=0x90 b=0x6 But compiled with gcc 4.6 (actually my test was with gcc trunk, but that is still fairly similar) -g -O2 -o foo.new foo.c systemtap is unable to find the value of most variables: $ stap -e 'probe process ("./foo.new").function("foo") { printf("%s@0x%x\n", pp(), uaddr()); log ($$vars) }' -c ./foo.new process("/tmp/foo.new").function("foo@/tmp/foo.c:8")@0x400aaa x=0x0 process("/tmp/foo.new").function("foo@/tmp/foo.c:8")@0x4004b0 a=? x=? b=?
Mark, is there reason to suspect systemtap here, or is this a pure gcc "guality" regression?
(In reply to comment #1) > Mark, is there reason to suspect systemtap here, or is this a pure gcc > "guality" regression? A quick looks shows gcc doing partial inlining of foo. Some of the variables might indeed not be available in the partial inlined version of foo that stap probes. So it might actually reflect reality in this case of where the probe gets placed. I think I just filed the testcase to do a deeper analysis of what is going on.
> A quick looks shows gcc doing partial inlining of foo. Some of the variables > might indeed not be available in the partial inlined version of foo that stap > probes. That may be, but the vta code has the capability to synthesize dwarf for some no-longer-existent variables, if their value may be derived from constants or other variables.
Looking at the debug_info shows some of these variables are available as const_value at other addresses. It might just be that staps heuristic of choosing the probe address doesn't match up with where gcc expects these constant values to materialize. This is a very synthetic testcase though.
with gcc 9.3.1 and current systemtap, the stap -v -L shows: process("foo").function("foo@foo.c:9") /* pc=.absolute+0x1170 */ $x:int process("foo").function("foo@foo.c:9") /* pc=.absolute+0x105a */ $b:int process("foo").function("foo@foo.c:9") /* pc=.absolute+0x106f */ $x:int $a:int $b:int so different variables in different inlined variants of the function. That seems about right.
commit 13d1ba6b86e806097e8c70777474f76cee182a25 Author: Frank Ch. Eigler <fche@redhat.com> Date: Fri Apr 10 20:37:06 2020 -0400 PR12609 redux: filter out duplicate probes due to partial-inining