[LLVMdev] Support for "foreign" Visual Studio 64 bits C++ exceptions?

Jérôme Couture-Gagnon Jerome.Couture-Gagnon at fabricengine.com
Thu Apr 12 14:02:26 PDT 2012


Hi,

We are currently porting our application to Windows 64 bits (amd64), and we are getting regressions from 32 bits relatively to LLVM 3.0's ability to get traversed by "foreign" Visual Studio C++ exceptions. That is, there is a crash when C++ exceptions which are thrown from Visual Studio code, are unwinding through LLVM code before being eventually catch by other Visual Studio code (more details below).

I am not an expert on the subject of exceptions, however I was not able to find clear answers about this specific issue. Should it be supported, and if not, is there is any planned effort from the LLVM team to work on this?

Note that we are not using the LLVM3.0 exception API (launchingPad with personality routine). In fact, this leads to another related question: is there even a "personality routine" available when compiling with Visual Studio? From what I read it looks like this would require support for Windows' SEH, which is not implemented yet. Any news or plans on that front? SEH was mentionned in the design discussion of LLVM3.0's exception API, without mentioning any plans to support it: http://groups.google.com/group/llvm-dev/browse_thread/thread/b7fc0999e9f11b8f/2cc43ddaba3bcff6?lnk=gst&q=SEH+exception#2cc43ddaba3bcff6

More details about the crash:

I was able to repro the issue simply by modifying the Fibonacci example to call an external C++ function which throws an exception, much like in ExceptionsDemo.cpp: works on 32 bits but not on 64 bits Visual Studio. The crash happens within Windows' _cxxThrowException routine. I read that the 64 bits exception handling in Windows is doing some unwinding in a different fashion than on 32 bits (as explained here: http://lackingrhoticity.blogspot.ca/2011/11/stack-unwinding-risks-on-64-bit-windows.html). In particular, this blog seems to state that exceptions won't unwind properly through functions that don't provide some unwind info, which is the case for LLVM I guess.

Thank you,

Jerome Couture-Gagnon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120412/e06b6ba9/attachment.html>


More information about the llvm-dev mailing list