[LLVMdev] RFC: New EH representation for MSVC compatibility

Kaylor, Andrew
Mon, 18 May 2015 18:02:44 -0000

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