On Mon, 2010-01-11 at 09:35 -0500, Masami Hiramatsu wrote:
...
Return probes are on the TODO list, but we actually already have a
pretty solid implementation of that. It's held out for now because
Srikar's patch set is already big, and we want get a review of the basic
ubp/xol/uprobes feature.
For the most part, we don't need special symbol information for return
probes. We just do as we did in kretprobes: hijack the return address
and replace it with the address of a trampoline. In user-space return
probes, the trampoline is one of the instruction slots in the XOL vma,
and contains a breakpoint to trap us into the kernel. (Of course, as in
kretprobes, we need to know the address of the function so we can hijack
the return address upon entry to the function.)
One place where symbol info would come in handy is when a function
returns in a weird way. We handle longjmps by noticing that the task's
stack is smaller than expected, and presumably missing stack frames that
were bypassed by the longjmp. But this heuristic gets dicey when you
consider that in a 32-bit x86 app, a struct-returning function pops not
only the return address upon return, but also the address of the
returned struct value. So it'd be nice to know if a function returns a
struct.
Does this answer your question, or did I miss something?
Yes, I think that's what Srikar meant: avoid single-stepping by adding a
jump instruction after the instruction-copy in the XOL slot -- as you
did in your kprobes-booster work. Your instruction-analysis work makes
this much more feasible.
Jim Keniston
--
