This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Accessing target variables in return probes (was Re: src ChangeLog tapsets.cxx)
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: <fche at redhat dot com>, "David Smith" <dsmith at redhat dot com>
- Cc: "Systemtap List" <systemtap at sources dot redhat dot com>
- Date: Thu, 14 Dec 2006 15:16:59 -0800
- Subject: RE: Accessing target variables in return probes (was Re: src ChangeLog tapsets.cxx)
On Thursday, December 14, 2006 12:09 PM, fche@redhat.com wrote:
> In case I didn't put this idea on paper already: one way may be to
> also store the thread's current stack pointer somewhere in the
> tracking data stream. If we realize that our "current" stack
> pointer is higher than that of the highest-nesting-numbered
> saved data record, we could unroll to recover synchronization.
Nice idea! Have you prototyped this at all?
We also discussed the possibility of extending kretprobes with a
pre_handler -- a handler that is called during entry, but only if the
return-probe instance was successfully allocated. I looked into it, and
it seems like a very minor change:
(fake patch example, in arch/x86_64/kernel/kprobes.c)
/* Called with kretprobe_lock held */
void __kprobes arch_prepare_kretprobe(struct kretprobe *rp,
struct pt_regs *regs)
{
unsigned long *sara = (unsigned long *)regs->rsp;
struct kretprobe_instance *ri;
if ((ri = get_free_rp_inst(rp)) != NULL) {
+ if (!(rp->pre_handler && rp->pre_handler(rp, regs))) {
ri->rp = rp;
ri->task = current;
ri->ret_addr = (kprobe_opcode_t *) *sara;
/* Replace the return addr with trampoline addr */
*sara = (unsigned long) &kretprobe_trampoline;
add_rp_inst(ri);
+ }
} else {
rp->nmissed++;
}
}
(Repeat for other archs, and add pre_handler to struct kretprobe...)
If we push for a patch like this to kprobes, then we can use it when the
kretprobe pre_handler is available, or else use your method for older
kernels.
Josh