This is the mail archive of the archer@sourceware.org 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]

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)


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