Re: function parameter access in kretprobe handler

[Jim Keniston <jkenisto@us.ibm.com>]

On Fri, 2006-01-06 at 01:40, Roland McGrath wrote:
> This subject has been discussed here before.  I'll try to summarize.
> 
> The DWARF information that's used for $foo variable accesses in theory
> always says for each PC either how to get the right value, or that it
> cannot be gotten.
> 
> kretprobes trap at the actual return site, after the function epilogue.
> At this point it is almost never possible to recover local variables like
> arguments.  However, since kretprobes are some special magic, there isn't
> a correct PC that the translator can use as context for getting $foo
> locations from DWARF.  If you set a normal kprobe at the end of a
> function, such as at the beginning of its epilogue, then it may be
> possible that more local variables are accessible.  However, there is
> never any guarantee that variables will be accessible if they are dead in
> the program at that point (which all are at the end of the function), and
> of course those local variables that were originally arguments may no
> longer have the original values passed in.  
> 
> The only completely reliable way to get a function's arguments in a return
> probe is to actually get them at function entry and store values for later
> use in the return probe.

Kprobes support for this is pretty easy.  Kevin wrote and tested a patch
that adds a user-defined "entry_info" pouch to a kretprobe_instance.  An
accompanying handler, entry_handler, is called to copy info (e.g., arg
values) into the pouch at function entry.  When the function returns,
the return-probe handler has access to these values:
http://sourceware.org/ml/systemtap/2005-q3/msg00593.html

Frank was lukewarm regarding this idea, I think mostly because DWARF can
tell you how to find arg values at the end of the function prolog, but
not right at entry to the function:
http://sourceware.org/ml/systemtap/2005-q3/msg00599.html

Finding the arg values on function entry is theoretically very
straightforward -- each architecture's ABI spells it out -- except that
for some architectures, declarations such as fastcall and asmlinkage map
to regparm attributes that alter where args are passed.  And it's my
understanding that DWARF doesn't provide a function's regparm value. 
That, I think, is the main obstacle to SystemTap using jprobes.

Correct me if I'm wrong.

Jim

> Right now, you just do that by hand by writing
> multiple probes and using global variables; it's not very pretty.  There
> has been some mention of a more automatic version of this feature wherein
> e.g. $foo references to arguments mentioned in a return probe would
> produce an implicit entry probe to collect those values and provide them
> to the return probe script code, without using any unsightly global
> variables at the systemtap language level.  Noone has pursued this idea much.
> 
> 
> Thanks,
> Roland
> 
>