[cfe-dev] Windows: How to catch C++ exceptions in runtime-compiled code?

[Timur Doumler via cfe-dev]

HI all,

Here in the JUCE team, we are working on porting the Projucer <https://www.juce.com/releases/projucer-juce-4> C++ live coding engine to Windows. Our main challenge now is how to catch C++ exceptions in runtime-compiled code on Windows. This doesn’t work for us and we’re quite stuck at this point. 

I recently had a chat about this with Chandler Carruth at C++Now. Chandler suggested that we post our problem to this mailing list, and that perhaps Reid Kleckner and/or other people here may have some hints. Any ideas would be highly appreciated!

In our case the RaiseException API function does not find the correct catch pad, which may be caused by a ThrowInfo structure handed to _CxxThrowException being empty. Apart from getting this right, is there anything else we possibly miss? Windows API functions to be called for registering catch pads or so?

Some more details:
We're using Clang for compiling C++ code at runtime and the ORC libraries to load and execute it in our application, which is itself compiled with MSVC. We work with the release_38 branches of LLVM and Clang.

Static compilation of a simple test program with try/catch and throw works fine. When compiling the same code at runtime and loading it with the ORC libraries, every throw results in an unhandled exception. The point of interest seems to be the throw handler for C++ exceptions (throw.cpp):

__declspec(noreturn) extern "C" void __stdcall
_CxxThrowException(void* pExceptionObject, _ThrowInfo* pThrowInfo)
{
    ...
    RaiseException( ThisException.ExceptionCode,
                    ThisException.ExceptionFlags,
                    ThisException.NumberParameters,
                    (PULONG_PTR)&ThisException.params );
}

For some reason the call to RaiseException does not find or consider the existing catch handler correctly. Comparing execution states when entering the function between the two cases, static- vs. runtime-compiled, turns out that pThrowInfo points to nulled memory in the runtime-compiled case, while it has some data in the static-compiled case. Detailed information about the types can be found here:  http://www.openrce.org/articles/full_view/21 <http://www.openrce.org/articles/full_view/21>. Most likely the "attributes" and "pCatchableTypeArray" members are required for RaiseException to resolve the correct catch pad?

To find out why the ThrowInfo structure is empty in the runtime-compiled case, we compared what happens during code generation. It looks like CodeGenFunction::EmitCXXThrowExpr is the relevant function here and it does the right thing, i.e. generating the global variable for the ThrowInfo in MicrosoftCXXABI::emitThrow. Also the WinEHPrepare pass is running correctly as it seems. Is there any extra work to do (at runtime/link-time?) for filling this data structure? Any idea what else to check?

Our Clang language options do include: Exceptions, CXXExceptions, RTTI, RTTIData

Please reply to my colleague Stefan Gränitz (in Cc) who is in charge of this project. Any kind of help or ideas would be really awesome.

Many thanks!
Timur
-- 

Timur Doumler
JUCE Senior Software Engineer
ROLI <http://www.roli.com/> extends the journey of music creation to everyone. The acclaimed  <http://www.roli.com/press/reviews>Seaboard GRAND <http://www.roli.com/products/seaboard-grand> and Seaboard RISE <http://www.roli.com/products/seaboard-rise> redefine how expressive and versatile an electronic musical instrument can be. Our groundbreaking software Equator <http://www.roli.com/equator> opens up new dimensions of sonic expression, and is built with JUCE <http://www.juce.com/>, ROLI’s proprietary coding platform, and the leading C++ framework for audio applications globally. Blend <http://www.blend.io/> enables everyone to seamlessly collaborate, share, and remix their music. And NOISE <http://www.roli.com/noise> is the most expressive app ever made — see for yourself: download it now for free! <https://itunes.apple.com/app/noise-5d/id1011132019?ls=1&mt=8>

Mobile: +44 (0) 7539 947960
Office: +44 (0) 2072 542155

ROLI 
2 Glebe Rd, London E8 4BD
www.roli.com <http://www.roli.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160610/29212819/attachment.html>