This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug uprobes/12275] uretprobes break exception handling
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: Tue, 7 Dec 2010 03:21:17 +0000
- Subject: [Bug uprobes/12275] uretprobes break exception handling
- Auto-submitted: auto-generated
- References: <bug-12275-1110@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12275
--- Comment #8 from Josh Stone <jistone at redhat dot com> 2010-12-07 03:20:53 UTC ---
The current design shares a single SSOL slot as the trampoline address of
uretprobes throughout the process. If we want a user-accessible "real" return
address stored predictably nearby, then we'll have to use a separate SSOL slot
as trampoline for each uretprobe hit. That also means eh_frame metadata would
have to be available for all of those.
That's partly why I came up with having a "catch" handler of our own, so in a
single trampoline we can hook uprobes to inject the real return address from
its in-kernel uretprobe_instance to wherever is convenient. And now that I've
read more of the exception ABI, I think it wouldn't actually have to be a full
C++ catch-rethrow. I think just having a low-level cleanup routine is
sufficient, which just needs our breakpoint hook, then call _Unwind_Resume. I
don't know if we could actually link _Unwind_Resume from something like a VDSO
handler though.
As a different strategy with the existing simple trampoline, maybe the eh_frame
metadata could inject a different kind of fault? Perhaps tell the unwinder
that the next return address is at *(MAGIC_BAD_ADDR), and let uprobes fix it
from there? We still have the pesky problem of hooking up our eh_frame, of
course.
I like the idea of putting the trampoline in the VDSO, including eh_frame data,
but it seems much more plausible with an in-kernel uprobes. Someday,
perhaps...
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.