Emiting code with Exception support - winapi

Question

I need to generate code at runtime that do the following:
auto v_cleanup = std::shared_ptr<void>(nullptr, [](void *){ cleanup(); });
//...
do_some_danger_thing();
//...
or C equivalent:
__try {
//...
do_some_danger_thing();
//...
} __finally {
cleanup();
}
The cleanup() function is guaranteed to be exception free, however do_some_danger_thing() may throw exception. This runtime code MUST not use stack, which means when calling do_some_danger_thing() the stack must in the same status as when we enter the runtime code, except that the return address set to the runtime code (the original value was saved to a "jmp" target, in order to return to the caller).
Because we are using dynamic machine code, the target platform is fixed to WIN32 on x86 CPU, the x64 CPU is not currently in focus.
To do this we have to process any exceptions. In WIN32 C++ exception is SEH based, so we have to due with it. The trouble is that we cannot find a way to do this and make it compatible with other code. We have tried a couple of solutions but none of them works, sometimes the user-installed exception handler was never called, sometimes the outer exception handlers was bypassed and we received an "unhandled exception" error.
UPDATE:
It seems to be the case that SEH exception handler chain supports code within the EXE image only. If the exception handler pointed to my generated code it will never been called. What I have to do is to create a static exception handler function stub, and then let it call the generated handler.

Answer 1

I am now have an implementation that is slightly different with the above. Actually, the pseudo code looks like (in C++11):
std::exception_ptr ex;
try {
//...
do_some_danger_things();
//...
} catch (...) {
ex = std::current_exception();
}
cleanup();
if(ex)rethrow_exception(ex);
This is not 100% the same as the above C equivalent because the call of cleanup() occurs before stack unwinding, usually this is not a problem, but the exact exception context could be lost.
I implemented an internal exception handler as the helper function, like the following:
_declspec(thread) void *real_handler = nullptr;
void **get_real_handler_addr(){
return &real_handler;
}
__declspec(naked) int exception_handler(...){
__asm {
call get_real_handler_addr;
mov eax, [eax];
jmp eax;
}
}
The trick here is that this handler must not be generated at runtime, so the stub has to find out where the "real" handler is. We use a thread local storage to do this.
Now the generated code will get the exception handler chain from FS:[0]. However, the chain must be stack based so I use the following code to replace the handler:
void **exception_chain;
__asm {
mov eax, fs:[0]
mov exception_chain, eax
}
//...
void *saved_handler = exception_chain[1];
exception_chain[1] = exception_handler;
*get_real_handler_addr() = generated_code->get_exception_handler();
The generated exception handler can then do the cleanup. However, in case that any current exception handler returns EXCEPTION_CONTINUE_SEARCH, the handler will be called twice. My strategy is just restore the original exception handler within the first call.