accessing args from return probe

[Kevin Stafford <kevinrs at us dot ibm dot com>]

I ran into a problem when considering system call tapsets. There are a 
significant amount of "getter" system calls that take user space pointer 
args that are eventually assigned in the function. Heres an example:
 
   asmlinkage long sys_time(int __user * tloc) {
       int i;
       struct timeval tv;
       do_gettimeofday(&tv);
       i = tv.tv_sec;
       if (tloc) {
               if (put_user(i,tloc))
                       i = -EFAULT;
       }
       return i;
   }

Here is what an appropriate tapset may look like for such a function:

  probe kernel.syscall.time = kernel.function("sys_time") {
     /* nothing to export, the param is
        meaningless to me at this point */
  }

  probe kernel.syscall.time.return =
     kernel.function("sys_time").return {
        /* now that the buf is
           assigned, export it */
        time = get_uint_ptr($tloc);
        retval = get_eax();
     }

This return probe will produce bogus results because by the time the 
return handler is executed, reference to the arg(s) have been clobbered. 
This is a problem that must be addressed as this type of behavior is 
prevalent in system calls.

Here is a workaround using two probes and a global as a record keeper:

  global time_tloc_addr

  probe kernel.syscall.time = kernel.function("sys_time") {
     /* save the addr of the arg while I can */
     time_tloc_addr[pid()] = $tloc
  }

  probe kernel.syscall.time.return =
     kernel.function("sys_time").return {
           time = get_uint_ptr(time_tloc_addr[pid()]);
           retval = get_eax();
     }

Indeed, this is ugly. It requires two probes to accomplish one task, and 
there are globals everywhere. Without changing kprobes, I do not see any 
other way to get at this data.
I would like peoples thoughts on alternative ways to overcome this 
challenge. Otherwise I will begin writing tapset code using the 
aforementioned approach. Of course another method is to simply not allow 
access to params at the return probe.

Thanks.

--
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com