This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

(retrospective) Re: Exception Handling Estimates

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]