This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: a different approach to accessing args from return probe
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Kevin Stafford <kevinrs at us dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: 26 Sep 2005 15:49:44 -0400
- Subject: Re: a different approach to accessing args from return probe
- References: <43382A56.8070700@us.ibm.com>
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