This is the mail archive of the systemtap@sourceware.org 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]

[Bug uprobes/12275] uretprobes break exception handling


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

--- Comment #9 from Josh Stone <jistone at redhat dot com> 2010-12-07 03:41:21 UTC ---
(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...

Then there's the matter of hooking exception dispatch itself.  I suppose this
needs probes on _Unwind_RaiseException and _Unwind_ForcedUnwind, maybe also
_Unwind_Resume.  And some point also to know that exception dispatch is
finished.

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 could be making a mountain out of a molehill, but I doubt that this
disarm-hack is really any easier to accomplish.

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


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