[Bug uprobes/12275] uretprobes break exception handling

["roland at gnu dot org" <sourceware-bugzilla at sourceware dot org>]

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

Roland McGrath <roland at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roland at gnu dot org

--- Comment #6 from Roland McGrath <roland at gnu dot org> 2010-12-03 03:00:48 UTC ---
A "catch and rethrow" is not necessarily what you need to model.
It really depends on what you are trying to get.

For merely making exception handling work, you don't need the retprobe
trampoline to appear to be a frame that catches.  It can just appear to be a
frame that does nothing with exceptions, but that can be unwound through to its
caller (i.e., the real caller of the probed function).  That is also what you
need for generic unwinding for backtraces (including by userland
unwinders/debuggers, not just ubacktrace()) not to be so confused by the
presence of the uretprobe trampoline.  That is far simpler metadata, just a
tiny bit that says how to derive the true caller's address.  If that address is
not already stored somewhere findable in user space, you can just stick the
address in the trampoline after the breakpoint instruction, so the metadata can
say to extract the address from the memory near the trampoline PC.  Or, if you
are generating metadata on the fly rather than using fixed metadata, it can
just include the literal address directly in the metadata.

Something more like what you suggest might be required to have a probe hit for
exceptions, though with some more thought we might come up with a way to
intercept that without actually using rethrow.

What so far still seems like the harder problem is getting the infrastructure
to find your metadata at all.  The trampoline lives in an SSOL slot, which is
some dynamically-allocated text page not envisioned before runtime.  To get
that found, you'd have to somehow wedge a new record into the list of objects
examined to find .eh_frame data, as if it were a DSO you'd dlopen'd or
suchlike.  That is doable with sufficient knowledge of the dynamic linker
bookkeeping and/or the EH code's hooks, but it seems fragile and not
immediately obvious.  It may be an easier tack to modify the vDSO's .eh_frame
data to claim to cover the SSOL area, since the vDSO is already in that list. 
But that is also fragile and nonobvious unless you modify the kernel's vDSO
source beforehand to leave some space to use for it or something.

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