[LLVMdev] RFC: New EH representation for MSVC compatibility

Steve Cheng
Sat, 16 May 2015 14:29:57 -0000

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