This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Exception Handling Estimates
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Wed, 03 Sep 2008 11:40:37 +0100
- Subject: Exception Handling Estimates
From the department of slightly wild guesses. I agonized over trying to
break down these estimates to a more atomic basis. But that is not going
to happen; especially as a lot of the investigations are still
on-going. That disclaimer out of the way, it's been a lot of fun.
I've learned quite a lot about C++ exception handlers, unwinding and
myriad other concepts. That being said, the foundation of knowledge that
I base these thoughts on can best be defined as rickety. So as I try to
estimate how to frobulate the gronkifier (a deliberate misquote of Phil
Edwards from a GDB and Exceptions mail thread from 2001), please do give
me comments, good-wit and guidance. My estimates are based on my thin
experience with GDB. If another more experienced hacker should tackle
the issues, they should be tuned down appropriately.
Task #1 (gnats pr 2493): Documentation change regarding the "catch"
command. The text needs to be updated regarding current "catch throw or
catch catch" support and the confusion between "raised exceptions" and
"c++ exceptions" clarified.
Estimate: 1t is a "simple documentation change". Should not take a day,
call it a week at the lowest granularity.
Critical Path: None
Blockers: None
Dependencies: None
Priority: Low
Task #2 (gnats pr 2494): "catch throw" and "catch catch" return control
of the inferior inside the: "__cxa_throw" and "__cxa_begin_catch"
functions respectively. This is not a very good user experience. I would
expect "catch throw" and "catch catch" to return control of the
inferior in the users' code, just before the throw or catch code
executes. The current infrastructure sets a breakpoint on: "__cxa_throw"
for "catch throw" and "__cxa_begin_catch" for "catch catch"
respectively. I believe that having the inferior stop here is
interesting for only a small subset of C++ users. The task here is
stopping the inferior at the throw/catch, instead of just after.
Estimate: Teach GDB to stop the return control in the appropriate frame.
As this is a low priority item, I've not spend a great deal of time
investigating it. 1 month is my tentative figure.
Critical Path: None
Blockers: None
Dependencies: None
Priority: Low
Task #3 (gnats pr 2495): Performing an inferior function call on a
function that contains a throw with an out-of-frame exception handler
causes GDB to lose control of the inferior. What I believe is happening
here is the "__cxa_throw" is invoking "__Unwind_RaiseException" and that
is attempting to find a handler during the _UA_SEARCH_PHASE step.
Because the handler exists in another frame, and this is an inferior
function call with a tinkered stack, the unwinder in not finding a
handler. This causes "__Unwind_RaiseException" to return with with the
error: _URC_END_OF_STACK and the default handler is called. I believe
this default handler just terminates the application. With a handler in
the frame, this does not occur as the handler is found in the inferior
function frame.
Estimate: Ian had a good idea here on setting a breakpoint on
__terminate_handler and not stepping the inferior beyond that. I'd
estimate 1-2 months here. There is a lot of skew in the estimate to
account for learning about momentary breakpoints and other GDB concepts.
Critical Path: None
Blockers: None
Dependencies: None
Priority: High (lose of control of inferior)
Task #4 (gnats pr 2488): Using "next" command over a C++ "throw"
causes GDB to lose control of the inferior. This has taken a large
amount of time as it involved having to step through the unwinder code
and fully map out the life-cycle of a C++ exception. At the most basic
level, the "next" command relies on longjmp breakpoints to reassert
control of the inferior after it has been resumed. Unfortunately this
will not work with the system unwinder when matching and then
transferring control to exceptions handlers.
Estimate: I think this will be the biggest task, and I've really
wrestled over it. It entails teaching GDB about methods of detecting
program flow control that do not entail setjmp/longjmp. The gory details
are archived on the list, so I will not regale them here. There is also
a question of where control should be returned that is still ongoing. 2
months.
Critical Path: None
Blockers: None
Dependencies: None
Priority: High (lose of control of inferior)