Re: [PATCH] Add Documentation/kprobes.txt

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

On Wed, 2005-08-03 at 03:41, Suparna Bhattacharya wrote:
> On Tue, Aug 02, 2005 at 03:20:06PM -0700, Jim Keniston wrote:
> > The enclosed patch creates Documentation/kprobes.txt, a guide to using
> > the existing Kprobes facility for dynamic kernel instrumentation.
> > Please apply.
...
> > +Here's how it works.  When the probe is hit, Kprobes makes a copy of
> > +the saved registers and a generous portion of the stack (see below).
> > +Kprobes then points the saved stack pointer at the stack-copy, points
> > +the saved instruction pointer at the jprobe's handler routine, and
> > +returns from the trap.  As a result, control passes to the handler,
> > +which is presented with the same register and stack contents as the
> > +probed function.  When it is done, the handler calls jprobe_return(),
> > +which traps again to restore processor state and switch back to the
> > +probed function.
> > +
> > +gcc assumes that the callee owns its arguments.  To prevent unexpected
> > +modifications to the probed function's stack, Kprobes presents the
> > +jprobe handler with a copy of the stack.  Up to MAX_STACK_SIZE bytes
> > +are copied -- e.g., 64 bytes on i386.
> 
> IIRC, we save and restore the stack, rather than pass a copy of the stack
> to the handler. Thus, while jprobes does make a copy of MAX_STACK_SIZE
> bytes, the handler still operates on the original stack (e.g. stack
> addresses are unchanged) and the stack contents are restored
> before returning control to the probed routine.
...

You're right.  Thanks.  I've modified those two paragraphs to read as
follows:
-----
Here's how it works.  When the probe is hit, Kprobes makes a copy of
the saved registers and a generous portion of the stack (see below).
Kprobes then points the saved instruction pointer at the jprobe's
handler routine, and returns from the trap.  As a result, control
passes to the handler, which is presented with the same register and
stack contents as the probed function.  When it is done, the handler
calls jprobe_return(), which traps again to restore the original stack
contents and processor state and switch to the probed function.

By convention, the callee owns its arguments, so gcc may produce code
that unexpectedly modifies that portion of the stack.  This is why
Kprobes saves a copy of the stack and restores it after the jprobe
handler has run.  Up to MAX_STACK_SIZE bytes are copied -- e.g.,
64 bytes on i386.
-----
Enclosed is the updated patch.  Please apply.

Jim Keniston

Acked-by: Prasanna S Panchamukhi <prasanna@in.ibm.com>
Signed-off-by: Jim Keniston <jkenisto@us.ibm.com>

Attachment: kprobes.txt.patch
Description: Text document