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]

uw_install_context() and GDB

Hi Jason,

One of tasks we have been looking at on Archer is the handling of C++ exceptions in GDB. In particular: if one uses the "next" command over a "throw foo" statement, control is lost of the inferior. This happens as the "next" command relies on setjmp/longjmp breakpoints to regain control of the inferior at the end of the sub-routine; but the unwinder install context does not use this mechanism and control is lost. Anyway, I'm sure you know far more of the C++ unwinder than me, so I'll just bypass the mechanics here.

So this leaves the question, if a user does perform a "next" over a C++ throw (or any function that results in the uw_install_context function being called), how we can regain control of the inferior?

There were two initial solutions.

The first was modifying the "next" command to place an implementation-internal breakpoint in __cxa_begin_catch, and comparing frames. (Is the frame that "next" was performed on above the current-frame? If so stop). But this method would skip any user-written destructors in the _UA_CLEANUP_PHASE. If any user-written destructors exist in the frame "next" was run on, or any frame inbetween that and the exception-handler, then the inferior should be stopped there - at the first one. This would be the proper behaviour for "next". Placing a breakpoint in __cxa_begin_catch would skip those. So I do not think this method is suitable.

The second was also modifying the "next" command to place an implementation-internal breakpoint in uw_install_context() itself. In actuality the breakpoint would be somewhere in uw_install_context_1 as uw_install_context is a macro, and the two built-in functions: __builtin_frob_return_addr and __builtin_eh_return. would be inlined. This allows us to teach GDB to step out of uw_install_context(_1) and allow us to return control from either the installed context via _UA_CLEANUP_PHASE or the final exception handling phase (name escapes me at the moment). This takes into account the stop at: user-written destructor if one exists, or at the corresponding catch statement. In full disclosure, I'm not entirely sure if this is possible, or how to implement this; it is firmly an idea. ;)

On the second solution, I wanted to run it by you too see if you find any issues (obvious or subtle, please let me know ;) Or if you have idea regarding catching context switches via uw_install_context()



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