[LLVMdev] RFC: New EH representation for MSVC compatibility

Steve Cheng steve.ckp at gmail.com
Mon May 18 12:40:34 PDT 2015


On 2015-05-18 14:02:44 -0400, Kaylor, Andrew said:

> We already have something like what you describe in the form of mingw 
> support.  It runs on Windows and handles exceptions using a DWARF-style 
> personality function and (I think) an LLVM-provided implementation of 
> the libc++abi library.
> 
> What this doesn't do is provide interoperability with MSVC-compiled 
> objects.  For instance, you can't throw an exception from MSVC-compiled 
> code and catch it with clang/LLVM-compiled code or vice versa.  With 
> the (too fragile) implementation we have in place right now you can do 
> that (at least in cases that don't break for other reasons), and we 
> want to be able to continue that capability with a new, more robust, 
> solution.

I skimmed the source code in libgcc of that personality function. It's 
rather tricky in that it threads the SEH personality function through 
an existing Itanium-style personality function. I agree completely that 
code might not be interoperable with MSVC, though I can't tell for 
sure. But I wasn't thinking of threading an Itanium-style personality. 
I was thinking of a personality that still adhered to SEH semantics as 
much as possible but lift the restrictions of _CxxFrameHandler3 that 
block what you're doing so far.

Even the problem that Reid mentioned about _CxxThrowException putting 
the exception object in the wrong place, I think, can be worked around 
with a new personality. The personality just has to copy the exception 
object into the stack frame of the function with the catch block (i.e. 
"landing pad" in Itanium parlance) before RtlUnwindEx transfers control 
to the landing pad. Obviously, you have to pre-allocate for the size of 
the exception object, I guess, in your WinEHPrepare pass. Obviously 
_CxxFrameHandler3 does not do that but we could.

Steve





More information about the llvm-dev mailing list