(retrospective) Re: Exception Handling Estimates

[Phil Muldoon <pmuldoon at redhat dot com>]

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 
> appropriately.

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 
> function frame.


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.

Regards

Phil