[Bug uprobes/5079] runtime/uprobes: stap module exit w/ outstanding uretprobe_instances

["dwilder at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From dwilder at us dot ibm dot com  2007-10-01 17:39 -------
> We could work around this on i386 and x86_64 by remembering the location, on the
> stack, of the return address, and stuffing the real return address back into the
> stack as part of unregister_uretprobe().  (That's how kretprobes was originally
> implemented.)  For the other architectures, though, this won't work, I'm told.

I investigated Jim's approach for the s390x (64-bit application only).  It could
possible to use Jim's approach however, I there are some special cases that my
not be possible to handle.

Here is a typical preamble/prolog on s390 (64-bit)
-When the function is called the return address is in GR14.
-The first instruction of the function pushes GR14 along with any other
registers that need to be saved onto the stack.  
- <function body goes here.>
-The prolog pops the return address off the stack in to any available general
register.
-Branch the to the address in the GR above.

It should be a simple matter for uprobes to calculate the address on the stack
where the return address will be saved.  Therefor the original return address
can be restored when removing the return probe.  

However, the are several exception cases we will need to handle:
1) The gcc may optimize out the saving of the RA because GR14 is never
overwritten by the function body.  We can handle this case by flagging that the
RA is stored in GR14 not on the stack.  When the return is removed we then place
the original RA directly in GR14.
2) When removing the return probe there is a small window where the return
address has already been popped from the stack.  Uprobes will have no way of
knowing this has occurred other than to search for the address of the trampoline
in all the GRs.  But this may be problematic.  If a GR contains the address of
the trampoline it could be coincidental or a left over from some other operation. 

I don't feel that case #2 can be handled safely.  

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5079

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.