Re: function parameter access in kretprobe handler

[Roland McGrath <roland at redhat dot com>]

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