Dave Korn <dave.korn.cyg...@googlemail.com> writes: > Really, it's all pretty much the same as DW2, except that rather than > calling a raise exception function in libgcc, it begins with a real processor > exception that then ends up routing into the unwinder. From there it's all > fairly analagous.
It sounds like it is different in (at least) two ways. First, an exception can occur while executing an instruction which accesses memory or does a division (admittedly only within a __try block). The raise exception call, on the other hand, can only occur during a function call. gcc's -fasynchronous-unwind-tables option is intended to support unwinding the stack at any precise instruction boundary, which might be adequate for this purpose if the OS can handle the adjustment from an exception in the middle of an instruction to an exception after the previous instruction is complete. Unfortunately, -fasynchronous-unwind-tables doesn't work; unwinding the stack during a function epilogue is not handled correctly. Second, it sounds like SEH permits execution to resume at the point of the exception, by having the exception handler function return ExceptionContinueExecution. I don't know how this could be implemented safely; it implies that the exception handler has some knowledge of how the program is compiled. I think the only possibility here is to just say that any use of ExceptionContinueException is undefined behaviour. This is unlikely to be satisfactory when porting existing programs, but perhaps that is not a significant consideration here. Also, the main reason for supporting SEH in gcc is so that it works with C++ exceptions, and they will never return ExceptionContinueException. Ian
