[Bug tapsets/13074] Some nfs tapset probes broken under linux 3.1-rc1

[mjw at redhat dot com]

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

--- Comment #4 from Mark Wielaard <mjw at redhat dot com> 2013-01-11 21:48:31 UTC ---
(In reply to comment #3)
> Looking at today's rawhide kernel (3.8.0-0.rc2.git3.1.fc19.x86_64), things are
> even more odd:
> 
> ====
> # stap -L 'module("nfsv2").function("nfs_proc_lookup").*'
> module("nfsv2").function("nfs_proc_lookup@fs/nfs/proc.c:148").call $arg:struct
> nfs_diropargs $res:struct nfs_diropok $msg:struct rpc_message
> module("nfsv2").function("nfs_proc_lookup@fs/nfs/proc.c:148").return
> $return:int $arg:struct nfs_diropargs $res:struct nfs_diropok $msg:struct
> rpc_message
> ====
> 
> Here's the source to nfs_proc_lookup. Looking at this, it appears that stap has
> confused local variables for parameters:

Note that for -L it doesn't matter (to stap) whether some accessible local is a
parameter or a variable. It just matters if it can use the DWARF to access it
at the probe location.

> Mark, got any thoughts as to what is going on here?

In this case $arg, $rest and $msg (local variables) have simple DWARF location
expressions (basically telling where on the stack they can be found). So they
are listed. While the actual parameters seem to have more complex location
descriptions (involving GNU_entry_val) so are deemed inaccessible, so most
aren't listed.

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