This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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. :-)

> 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

> Hey, If this works for i386, why not go and implement it...
> -Anil


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]