[LLVMdev] RFC: New EH representation for MSVC compatibility

[Kaylor, Andrew]

No, we're talking about 32- and 64-bit programs.  The goal is specifically to get these programs to work with the MSVC runtime.  If the MSVC runtime starts handling an exception (for instance, within a library compiled with MSVC) it is only going to dispatch that exception to a handler that it is able to recognize.

If all you are interested in is handling exceptions within a closed system, then there are certainly a lot of ways it can be accomplished.  It's the desire for MSVC compatibility that constrains the implementation.

-----Original Message-----
From: Vadim Chugunov [mailto:vadimcn at gmail.com] 
Sent: Monday, May 18, 2015 11:17 AM
To: Kaylor, Andrew
Cc: Steve Cheng; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] RFC: New EH representation for MSVC compatibility

Are you guys talking specifically about Win32 EH here?   AFAIK, Win64
EH works with gcc-style personality routines just fine.

On Mon, May 18, 2015 at 11:02 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev