Re: a different approach to accessing args from return probe

[fche at redhat dot com (Frank Ch. Eigler)]

kevinrs wrote:

> [...]  The attached patch to kprobes provides a convenient way to
> remember the original values of a function's args and make them
> available to the return-probe handler. It adds these members to
> struct kretprobe and struct kretprobe_instance [...]

Interesting solution, though it requires a great deal of hand-written
per-probe, per-architecture, low-level C code.

Yet another alternative would be to teach the translator to emit a
pair of probe points for each .return (or a new variant like
.return.params), the additional one likewise at the entry.  The first
would be entirely synthesized and would automagically copy all local
function parameters into hidden script-level globals.  The second
would run the user-provided handler, but expanding $paramN to refer to
those globals.  In other words, let the translator manage the
snapshotting process and its variables, automating the hand-written
script-level machinery first outlined by Kevin.

One drawback to this is that the most straightforward implementation
would involve a new kprobe in the usual just-past-prologue spot, where
the usual symbolic resolution of variable names/types/locations is
valid (bug #1295 is a prerequisite).

- FChE