5

I met a problem when inspecting the local variables of user space application in systemtap.

I write a test.c like this:

#include <stdio.h>

int func(int *p, int val)
{
        printf("p=%p val=%d\n", p, val);
        return 1;
}

int main()
{
        int a = 7;
        func(&a, a);
        return 0;
}

and compile it with -g

# gcc -g -o test test.c

Systemtap can see the variable of func(): p and val

# stap -L 'process("./test").function("func")'
process("/home/ryan/Public/test").function("func@/home/ryan/Public/test.c:3") $p:int* $val:int

So I use this stp to watch the variables:

# stap -e 'probe process("./test").function("func") {printf("%s(%p, %d)\n", probefunc(), $p, $val)}'

But the local variables are not right in the result when test program executed, it shows:

func(0x0, 0)

I am using fedora19 with:

kernel-3.11.9-200.fc19.x86_64
systemtap-sdt-devel-2.3-1.fc19.x86_64
systemtap-2.3-1.fc19.x86_64
systemtap-client-2.3-1.fc19.x86_64
systemtap-devel-2.3-1.fc19.x86_64
systemtap-runtime-2.3-1.fc19.x86_64
gcc-4.8.2-7.fc19.x86_64

Could someone meet this problem or give me a solution?

Jincheng Miao
  • 53
  • 5

1 Answers1

4

.function probes are defined to fire at entry to the function. If you're looking for values of local variables, you need to use .statement probes, identifying the source-file:line-number. In this case though, you're looking for parameters to a function (which happened to be based on another function's locals). In this case, the .function probe is appropriate.

You appear to be hitting a GCC bug. In plain -g mode (ironically), dwarf debuginfo is sometimes inaccurate for incoming function parameters. Try "gcc -g -O" or "gcc -g -O2" instead. Systemtap prologue-searching (stap -P) might help. See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358, https://sourceware.org/bugzilla/show_bug.cgi?id=13420

In case the "stap -P" doesn't help, you may need to resort to statement-level probing after all:

probe process("./test").statement("func@test.c:5") { println($$parms) }

(line :5 refers to the printf)

fche
  • 2,641
  • 20
  • 28
  • Thanks Frank, you are right, it's gcc's bug. With option '-O' compiled, I can get the the right local variable values. With '-O2', the local var int *p will be optimized, so semantic check fails. But for stap -Pe 'probe process("./test").function("func") {printf("%s(%p, %d)\n", probefunc(), $p, $val)}', I still can't get the right answer, did I mis-used it? – Jincheng Miao Dec 26 '13 at 10:01
  • Yes, I can get the right answer using statement even without gcc optimization. This is gcc's fault "incorrect/missing location for function arg, -O0", as bug title said. So currently, the best way to inspect variable of user space function is using statement probe. – Jincheng Miao Dec 27 '13 at 03:25