This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: return probes and stack traces
- From: Jim Keniston <jkenisto at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: 28 Jun 2005 16:22:35 -0700
- Subject: Re: return probes and stack traces
- Organization:
- References: <200506282050.j5SKoPj2014374@magilla.sf.frob.com>
On Tue, 2005-06-28 at 13:50, Roland McGrath wrote:
> I don't see why the kretprobe stuff couldn't restore the original
return
> address to the stack while running the probe handler.
I'm not sure what you have in mind. When the return-probe handler is
called, the return address has already been popped off the stack by the
return instruction. We can't stuff it back into the stack without
overwriting a register (e.g., eflags) that was saved when the trampoline
probe was hit.
Rusty's correct that you can find the real return address if you look in
the right kretprobe_instance object. Since we no longer store the stack
pointer in the kretprobe_instance object, it might be a little more
challenging than it was on some architectures.
Basically, I think, you have to iterate through your task's hash list in
kretprobe_inst_table, matching kretprobe_instances on the list with
occurrences of the trampoline address in the stack. As long as it's
your own task that you're doing the stack trace for, it should be OK.
(Each task adds and removes its own kretprobe_instances in the hash
list.)
Jim