This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: function parameter access in kretprobe handler
- From: Jim Keniston <jkenisto at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>, SystemTAP <systemtap at sources dot redhat dot com>
- Date: 06 Jan 2006 13:34:58 -0800
- Subject: Re: function parameter access in kretprobe handler
- Organization:
- References: <20060106094023.AB6E0180B7C@magilla.sf.frob.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
>
>