This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
uw_install_context() and GDB
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Project Archer <archer at sourceware dot org>, jason at redhat dot com
- Date: Thu, 14 Aug 2008 17:46:32 +0100
- Subject: uw_install_context() and GDB
Hi Jason,
One of tasks we have been looking at on Archer is the handling of C++
exceptions in GDB. In particular: if one uses the "next" command over a
"throw foo" statement, control is lost of the inferior. This happens as
the "next" command relies on setjmp/longjmp breakpoints to regain
control of the inferior at the end of the sub-routine; but the unwinder
install context does not use this mechanism and control is lost.
Anyway, I'm sure you know far more of the C++ unwinder than me, so I'll
just bypass the mechanics here.
So this leaves the question, if a user does perform a "next" over a C++
throw (or any function that results in the uw_install_context function
being called), how we can regain control of the inferior?
There were two initial solutions.
The first was modifying the "next" command to place an
implementation-internal breakpoint in __cxa_begin_catch, and comparing
frames. (Is the frame that "next" was performed on above the
current-frame? If so stop). But this method would skip any user-written
destructors in the _UA_CLEANUP_PHASE. If any user-written destructors
exist in the frame "next" was run on, or any frame inbetween that and
the exception-handler, then the inferior should be stopped there - at
the first one. This would be the proper behaviour for "next". Placing
a breakpoint in __cxa_begin_catch would skip those. So I do not think
this method is suitable.
The second was also modifying the "next" command to place an
implementation-internal breakpoint in uw_install_context() itself. In
actuality the breakpoint would be somewhere in uw_install_context_1 as
uw_install_context is a macro, and the two built-in functions:
__builtin_frob_return_addr and __builtin_eh_return. would be
inlined. This allows us to teach GDB to step out of
uw_install_context(_1) and allow us to return control from either the
installed context via _UA_CLEANUP_PHASE or the final exception handling
phase (name escapes me at the moment). This takes into account the stop
at: user-written destructor if one exists, or at the corresponding catch
statement. In full disclosure, I'm not entirely sure if this is
possible, or how to implement this; it is firmly an idea. ;)
On the second solution, I wanted to run it by you too see if you find
any issues (obvious or subtle, please let me know ;) Or if you have idea
regarding catching context switches via uw_install_context()
Thanks
Phil