This is the mail archive of the
mailing list for the Archer project.
(retrospective) Re: Exception Handling Estimates
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Thu, 23 Oct 2008 22:15:07 +0100
- Subject: (retrospective) Re: Exception Handling Estimates
- References: <48BE69A5.firstname.lastname@example.org>
Phil Muldoon wrote:
A bit of a retrospective as requested. I thought it would be appropriate
to reply to the original estimate.
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
I did not get a reply to this email, which was a little frustrating. It
took a lot of work. It is understandable though. Even to have a good
grasp of the PRs required quite an investment of time. And looking
back, I did not comment on other hackers' estimates either - I was too
worried about my own. So I can't exactly gripe too loudly. Anyway, now
that the stress in generating them has gone, I think I'll take some time
to go back and re-read other folks estimates.
On another note, I did get lots of replies to individual ideas I posted
(and continue to post), so that was a lot more satisfying.
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.
About a week here, as I did not account for the gdb.texinfo change at
all, just the code change. The text changes I think are mainly trivial.
But changing texinfo and checking the rendering to html/pdf/info etc.
is surprisingly "fiddly". Also a lot of test-cases actually test the
text returned from GDB via expect. So while I do not expect this
particular text change in the code to actually affect any tests, it is
worth bearing in mind for other text changes.
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.
This I imagine would involve frame_pop() the inferior back one frame,
and letting the user step from there. I'm not exactly sure this is the
right solution. Execution to point n then pulling back to point z every
time seems kind of hacky. I've no clue how else to break on a throw or
a a catch. It seems mainly a cosmetic user issue. I'd stay the same on
this, maybe trim off a week. I did not account for gdb.texinfo changes here.
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
This was less scary to fix that I thought. I submitted a patch for this
already, received comments, and submitted a follow-up patch. I totally
underestimated the time it took to track down regressions in existing
tests. The code I was changing was well used throughout GDB and
subsequently in each test-case. make check in gdb/ takes a very long
time. Add in kernel changes and it adds up to a lot of time. Just
running runtest on individual tests helps a lot, but does not give an
overall picture. I really need to use Tom's GDB on GCC build farm idea -
it would save bags of time. I overestimated the actual code change. It
was pretty small. I underestimated: tracking and fixing regressions,
writing individual tests and documentation changes. All in, it took a
about 3 weeks of work.
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.
I'm still researching this one, and have no real clue. I'd actually add
weeks to this. It seems quite a substantial feat for a newbie to teach
GDB to stop on events in the unwinder other than longjmps. Perhaps I
will be more optimistic on this after buckling down and researching
this more in depth. This is my current task. I'll report back in a
month, with another retrospective.