systemtap : Able to access local variables but cannot access local pointers

Question

I have a dumb question, I wanted to understand the source code flow with the help of system tap, for this i was trying to access a local variable using kernel.statement probe function, it displays all the other variable except pointers.

probe module("Module_Path/proc_rw.ko").statement("my_write@Module Src Path/proc_rw.c+9")
{
    printf("local = %s\n", $$locals)
}


Module Code :
static ssize_t my_write(struct file *f, const char __user *buf, size_t len, loff_t *off)
{
        pid_t pid;
        int ret;
        struct task_struct *task_local;
        int *i;       
        ret=copy_from_user(c, buf, len);
        i=&ret;
        pid=simple_strtol(buf, NULL, 10);
        task_local=pid_task(find_vpid(pid), PIDTYPE_PID);
        return len;
}

When i execute above stap code, it returns,

local = pid=0xf98 ret=0x0 task_local=? i=?

Any help to understand why task_local and i values are not printed would be helpful.

Regards, Yash.

fche · Answer 1 · 2016-01-22T23:27:43.203

What you're seeing here is an artefact of compiler optimization. Variables that are no longer used may have their resources released (registers or stack frame slots reused), so even though they are theoretically in scope, there may be no value to read any more.

You'd see the same thing if you ran gdb on an analogous program and stepped to a far-down line, then tried to print those variables. Or try:

stap -L 'module("Module_Path/proc_rw.ko").statement("my_write@*:*")'

to see a dump of the statements & variables available at each.

Also, see https://lkml.org/lkml/2015/4/23/605 for a kernel patch that aimed to undo a recent (2014-10) undesirable reduction in debuginfo quality. (It wasn't merged.) But you can fix it for your own module by customizing your own Makefile.

systemtap : Able to access local variables but cannot access local pointers

1 Answers1