function parameter access in kretprobe handler

function parameter access in kretprobe handler

[Mao, Bibo]

Hi, 
	I remembered that previously I saw some scripts where function
parameter is accessed in return probe function. But I think that
currently systemtap has not this capability. 
	Because return probe handler happens when function returns and
causes one trap, sometimes function parameter is passed by register, for
example in IA32 the first parameter is passed by EAX register, and EAX
register can be changed during execution of this function. So when
return probe handler happens, if it accesses the first parameter by EAX
register, it will be wrong value.
	I do not know what is wrong with my thought.

Regards
Bibo,mao

Re: function parameter access in kretprobe handler

[Frank Ch. Eigler]

bibo.mao@intel.com wrote:

> I remembered that previously I saw some scripts where function
> parameter is accessed in return probe function. But I think that
> currently systemtap has not this capability. [...]

Correct.  Please see bug #1382.

- FChE

Re: function parameter access in kretprobe handler

[Roland McGrath]

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.  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

Re: function parameter access in kretprobe handler

[Jim Keniston]

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
> 
> 

Re: function parameter access in kretprobe handler

[Roland McGrath]

> 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

This is the case with older compilers and due to bugs perhaps still the
case in gcc 4.0.x.  At least as of gcc 4.1, we think that the DWARF info is
correct throughout the prologue and epilogue regions.  But this is indeed a
problem for practical needs today.

> 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 is all correct.  We may well extend the DWARF info in future to
indicate the calling convention selection, but so far it is not knowable
after compile time.  


Thanks,
Roland