[Bug uprobes/12275] uretprobes break exception handling

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

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

Jim Keniston <jkenisto at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ananth at in dot ibm.com,
                   |                            |srikar at linux dot
                   |                            |vnet.ibm.com

--- Comment #13 from Jim Keniston <jkenisto at us dot ibm.com> 2010-12-08 22:07:24 UTC ---
(In reply to comment #9)
> (In reply to comment #7)
> > For reference, another short-term hack would be to disarm
> > some or all uretprobes while an exception dispatch is in
> > progress.
> 
> I mentioned this idea to Jim, and he told me that it's not a simple thing to
> disarm uretprobes.  The current design doesn't really disarm anything, even
> after unregister_uretprobe -- it just zeros the handler so the next hit does
> nothing.  On x86, we could actually restore the return addresses throughout the
> stack, but on other architectures like powerpc we can't generally predict where
> the fixup is needed.  Perhaps if uprobes had a full unwinder...

Adding Ananth and Srikar to the cc list.  Is ppc64 unwind data sufficient to
enable stap to figure out where a function's return address is stored? Seems
pretty basic.

...
> 
> Maybe stap can register for these extra probepoints, provided enough debuginfo,
> and also perform the unwinding to figure out how to restore the return
> addresses.  This means "proper" uretprobes behavior would be depending on its
> client (stap), but I'm not sure we want uprobes to grow all this functionality
> itself.

I wouldn't let that stand in your way.  The number of uprobes users who aren't
also stap users can't be very big.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.