[LLVMdev] RFC: New EH representation for MSVC compatibility

[Kaylor, Andrew]

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.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Steve Cheng
Sent: Saturday, May 16, 2015 7:30 AM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] RFC: New EH representation for MSVC compatibility

On 2015-05-15 18:37:58 -0400, Reid Kleckner said:

> After a long tale of sorrow and woe, my colleagues and I stand here 
> before you defeated. The Itanium EH representation is not amenable to 
> implementing MSVC-compatible exceptions. We need a new representation 
> that preserves information about how try-catch blocks are nested.

Hi,

Newbie here. This must be a dumb question, but it's not something I can understand from reading the design documents and RFCs.

Why don't we write and use our own personality function, and then we avoid all these restrictions on the interval tables? On Windows, we would still have to catch exceptions with SEH, of course. But SEH should be language-independent, in the sense that it concerns only unwinding for the "low level" parts of the ABI, like restoring non-volatile registers. It doesn't seem to make sense that LLVM, being a language-independent IR, should concern itself with personality functions specific to Microsoft's C++ run-time library.

I understand we want to link compatibility with object code from Visual Studio, but I didn't think that the personality-specific unwind tables were actually an ABI "artifact". I mean, let's say you compile a function in Visual Studio, the result is a function with some mangled symbol that other object code can make references through the linker. 
But the other object code never incestuously refers to the unwind tables of the function it calls, right?

I'm speaking from the point of view of an implementor of a new programming language who wants to interoperate with C++. I've already got code that can decode the Microsoft RTTI info coming from C++ exceptions, and the pointers to those can be extracted with SEH GetExceptionPointers, etc. To support catching exceptions in my language, or at least calling cleanups while unwinding, I really don't care about the C++ personality function. After all my language might not even have the concept of (nested) try/catch blocks. The custom personality function does have to be supplied as part of the run-time, but as a frontend implementor I'm prepared to have to write a run-time anyway.

Steve


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev