Llvm generated instruction calls a function (extern), the function will have a SEH exception (EXCEPTION_ACCESS_VIOLATION), But JIT can not capture the exception of the EXCEPTION_ACCESS_VIOLATION. I saw Bug 24233. EXCEPTION_ACCESS_VIOLATION exception cannot be captured after modification.
How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 ?
I make mistakes. SE can be catched.
https://bugs.llvm.org//show_bug.cgi?id=24233. The example can catch exception. But I use my own code for testing, CustomEHMemoryManager allocated memory address is very large, allocateCodeSection, allocateDataSection assigned address (more than 32 bit address space) is getting smaller and smaller. Cause registerEHFrames to fail.
3.9.1 or 4.0.0 version has been supported on win x64? Or how to solve this problem?
I would not expect you to be able to catch any exceptions originating from code JITed by LLVM on Win64. Nobody has implemented the code to register the unwind data necessary to do this. The linked bug describes the steps necessary to implement this functionality.
Thank you for your reply.
Can the function be implemented by exception handling instructions(http://llvm.org/docs/ExceptionHandling.html#id34)?
Depending on your tolerance of imposing other constraints and debugging hacks, it can be possible to enable just enough exception handling. For the JuliaLang JIT, we force off FPO on all functions, then in the NotifyObjectEmitted callback, we can hand-code the expected stack frame prologue layout (https://github.com/JuliaLang/julia/blob/35422b2233788c31af93d4b41e6239f6bb20cc3a/src/debuginfo.cpp#L474-L488) and add it to the RTLFunctionTable (https://github.com/JuliaLang/julia/blob/35422b2233788c31af93d4b41e6239f6bb20cc3a/src/debuginfo.cpp#L156-L160). It’s not particularly elegant,
but it does make the stack walker happy enough to permit us to handle async exceptions and do statistical profiling.
The exception handling instructions work if you are emitting static code. But the relocations are not implemented in the JIT, nor is the memory manager able to ensure that the object layout will be valid, so there is no OOTB solution right now in LLVM.