[LLVMdev] RFC: New EH representation for MSVC compatibility

Steve Cheng steve.ckp at gmail.com
Sat May 16 07:29:57 PDT 2015


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





More information about the llvm-dev mailing list