This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: utrace-based uprobes
On Fri, 2007-03-16 at 17:28 -0700, Keshavamurthy, Anil S wrote:
> On Fri, Mar 16, 2007 at 04:46:42PM -0700, Keshavamurthy, Anil S wrote:
> > >
> > > >
> > > > > +If the number of times a function is called does not match the
> > > > > +number of times it returns (e.g., if a function exits via longjmp()),
> > > > > +registering a return probe on that function may produce undesirable
> > > > > +results.
> > > >
> > > > What do these undesirable results include
> > >
> > > Returning to the wrong address. For example, if A calls B, and you have
> > > uretprobes on both A and B, and B longjmps back into A, B's return
> > > address will be left atop that task's stack of return addresses. So
> > > when A returns, it'll return using B's return address.
> >
> > Isn't the behavior the same even without the return probes
> > inserted on A and B?
No. If setjmp/longjmp works properly, A returns using A's return
address. :-)
> Ha..now I see why you are having issues, can't you save rsp or esp too
> when you first enter the function in prepare_kretprobe, and in the
> trampoline handler instead of blindly assuming that the first instance
> to contain the real address, you can instead check for rsp or esp too
> to make sure you are replacing the real return address. This solution
> should work for i386 and x86-64 but I doubt that this will work for
> ia64 or ppc64.
We don't need the return address to be stored on the stack in order for
this check to work. We just need there to be a predictable relationship
between the the stack pointer's value when the function enters and the
SP's value after the return instruction is executed. Seems like a basic
requirement for a working ABI. Is that really not the case on ia64 or
ppc64?
> Hey, If this works for i386, why not go and implement it...
>
> -Anil
Jim