Re: Kprobes support for accessing args upon return

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Wed, 2006-12-06 at 18:35, Frank Ch. Eigler wrote:
> Jim Keniston <jkenisto@us.ibm.com> writes:
> 
> > As promised, here (once again) is a pointer to the kretprobes patch
> > (against 2.6.13) that adds an optional "data pouch" to a
> > kretprobe_instance. [....]
> 
> The main problem with this has been that, at the point where the entry
> half of the kretprobe fires, we may not have good quality debugging
> information to let us symbolically locate all the needed arguments.
> So, unfortunately, we currently use a normal, post-prologue kprobe to
> collect them.

Yes, but... I later coded (and tested?  Can't remember.) a function
called current_kretprobe_instance(), which could be called by a
post-prologue handler or a jprobe handler (since jprobe handlers always
run last of the entry handlers) to get the most recently pushed
kretprobe_instance for the current task and specified kretprobe.  It's
attached.  (Theoretically, you could call this any time during execution
of the probed function.)

As I recall, it's reliable unless the probed function is recursive AND
there's a chance you'll run out of kretprobe_instances.  In that case,
you can't be sure whether the returned kretprobe_instance is from the
current instance of the function or one up the call stack.  I imagine
you could put something in the "pouch" (e.g., the stack pointer) to help
disambiguate, but I was never able to solve that particular puzzle.

> 
> > The patch itself is quite simple, as you can see.  How to express
> > this feature in the SystemTap language was never nailed down.
> 
> It seems to me that the current (new) syntax could work unchanged
> for this alternate backend.

Where is the new syntax documented?  I didn't see it in the stap or
stapprobes man pages.

> 
> - FChE

Thanks.
Jim

Attachment: current_kretprobe_instance.txt
Description: Text document