llvm dev - May 2015 - [LLVMdev] RFC: New EH representation for MSVC compatibility

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

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

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

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

On 2015-05-18 15:40:34 -0400, I said:
> 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
Should have thought more before opening my mouth :)
Scratch that because it won't work with rethrows unless I get to patch 
the address of the in-flight exception object. Damn global variables.