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

On Mon, May 18, 2015 at 11:48 AM, Steve Cheng <steve.ckp at gmail.com>
wrote:
> On 2015-05-18 13:32:54 -0400, Reid Kleckner said:
>
>>
>> Right, doing our own personality function is possible, but still has
half
>> the challenge of using __CxxFrameHandler3, and introduces a new runtime
>> dependency that isn't there currently. Given that it won't save
that much
>> work, I'd rather not introduce a dependency that wasn't there
before.
>>
>> The reason it's still hard is that you have to split the main
function up
>> into more than one subfunction.
>>
>
> I see, but I thought are able to outline cleanup code already?
>
We can, but frankly it's unreliable. The new representation should help
make the job easier.

> And that the hiccup you are encountering is because __CxxFrameHandler3
> requires unwind tables with properly-ordered state transitions? The
> compiler SEH personality (_C_specific_handler) doesn't have that,
right? If
> you could manage __try, __finally already, doesn't that provide the
> solution?
>
Right, __CxxFrameHandler3 is a lot more constraining than
__C_specific_handler. The SEH personality doesn't let you rethrow
exceptions, so once you catch the exception you're done, you're in the
parent function. My understanding is that C++ works by having an active
catch handler on the stack.

> Let me be precise. Let's take your example with the "ambiguous IR
> lowering":

I snipped the example, but in general, yes, I agree we could do another
personality with a less restrictive table format. I'm still not convinced
it's worth it.

 The exception object is allocated in the frame of the function
calling
>> __CxxThrow, and it has to stay alive until control leaves the catch
block
>> receiving the exception.
>> This is different from Itanium, where the exception object is
constructed
>> in heap memory and the pointer is saved in TLS. If this were not the
case,
>> we'd use the __gxx_personaltity_v0-style landingpad approach and
make a new
>> personality variant that understands MS RTTI.
>>
>
> I'm surprised, I really want to check this myself later this week. I
> always thought that MSVCRT always copied your exception object because I
> have always seen it invoking the copy constructor on throw X. (It was a
> pain in my case because I didn't really want my exception objects to be
> copyable, only movable, and at least VS 2010 still insisted that I
> implement a copy constructor.)
>
Right, the type does have to be copyable. I think it's supposed to be
copied as part of the throw-expression, but if not, then it has to go fill
out the CatchableType tables, which have copy constructors in them. Anyway,
I might be wrong about where precisely the exception lives in memory, but
I'm sure the catches are outlined to support rethrow.

> Furthermore, the "catch info" in the MS ABI does have a field for
the
> destructor that the catch block has to call. It's not theoretical,
I've got
> code that calls that function pointer so I can properly catch C++
> exceptions from a SEH handler. Though I might be mistaken in that the field
> points to just an in-place destructor and not a deleting destructor.
>
Yep.

> Also, I thought the stack already is unwinded completely when you reach
> the beginning of the catch block (but not a __finally block, i.e. the
> cleanup code). At least, that's the impression I get from reading
> reverse-engineered source code for the personality functions and the
> Windows API RtlUnwindEx.

For __try / __except, yes, the stack is unwound at the point of the
__except. For try / catch, the stack unwinds after you leave the catch body
by fallthrough, goto, break, continue, return or whatever else you like,
because after that point you cannot rethrow anymore.

We could try to do all this outlining in Clang, but that blocks a lot
of
>> LLVM optimizations. Any object with a destructor (std::string) is now
>> escaped into the funclet that calls the destructor, and simple
>> transformations (SROA) require interprocedural analysis. This affects
the
>> code on the normal code path and not just the exceptional path. While
EH
>> constructs like try / catch are fairly rare in C++, destructor cleanups
are
>> very, very common, and I'd rather not pessimize so much code.
>>
>
> Right, but __CxxFrameHandler3 already forces you to outline destructor
> cleanups into funclets. So if you wanted to stop doing that you have to
> write your own personality function right?
>
No, I believe if we want to be able ABI compatible, we need to outline at
least destructor cleanups, regardless of what personality we use.

> What I am saying is, if you can design the personality function so that it
> works naturally with LLVM IR --- which can't see the source-level
scopes
> --- that seems a whole lot less work versus:
>
> * Changing the existing Itanium-based EH model in LLVM
> * Incurring the wrath of people who like the Itanium model
> * Having to maintain backwards compatibility or provide an upgrade path
>
So, the nice thing about this design is that there are no scopes in normal
control flow. The scoping is all built into the EH blocks, which most
optimization passes don't care about. If you do a quick search through
lib/Transforms, you'll see there are very few passes that operate on
LandingPadInst and ResumeInst. Changing these instructions is actually
relatively cheap, if we can agree on the new semantics.

> Also, I think, if we want to eventually support trapped operations (some
> kind of invoke div_with_trap mentioned in another thread), wouldn't it
be
> way easier to implement and optimize if the personality function can be
> designed in the right way?

Right, asynch exceptions are definitely something that users keep asking
for, so I'd like to see it done right if we want to do it at all. I think
this change is separable, though. Asynch exceptions have a lot more to do
with how you represent the potentially trapping operations (BB unwind
labels, lots of invoked-intrinsics, more instructions) than how you
represent the things to do on exception.

Thanks for taking a look!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/c91e0774/attachment.html>

Hi Reid,
> Right, __CxxFrameHandler3 is a lot more constraining than 
> __C_specific_handler. The SEH personality doesn't let you rethrow 
> exceptions, so once you catch the exception you're done, you're in
the
> parent function. My understanding is that C++ works by having an active 
> catch handler on the stack.
Okay, I checked the Wine source code for __CxxFrameHandler3. I stand corrected.

While we are on the topic of Windows EH, I like to know your (and 
others', of course) thoughts on the following. It's my wishlist as a 
frontend implementor :)

- Win32 (x86) frame-based SEH

For __CxxFrameHandler3, since destructors and catch blocks execute as 
funclets while the throwing function's stack frame is still active, 
it's not going to be a problem right?

But for __C_specific_handler, I see a potential issue versus x86-64, in 
that RtlUnwind can't restore non-volatile registers, so when registers 
are garbage when control is transferred to the landing pad.  When I 
read the Itanium ABI documentation, it says that landing pads do get 
non-volatile registers restored, so I guess that's probably the working 
assumption of LLVM.

 __C_specific_handler's registration frame saves down EBP, but no other 
registers, even ESP. If we use dynamic alloca or frame pointer 
omission, we are dead in the water, right?

- Writing one's own personality functions

This makes a lot of sense if one is implementing a different language 
than C++ that has exceptions, and is prepared to provide their own 
run-time support.

Say, if the language supports resuming from exceptions, or can query 
type information in more flexible ways than C++'s std::type_info 
matching. Does it really make sense for the backend, LLVM, to hard-code 
knowledge about the language-specific data area (LSDA)? Even in the 
Itanium ABI it's explicitly stated that the personality is specific to 
the source language, yet multiple personalities can interoperate in the 
same program. Ideally, I would prefer the backend to take control of 
everything to do with arranging the landing pads, branches within 
landing pads, and so on, but NOT the language-dependent exception 
matching.

Taken to the extreme, LLVM would have to expose tables that the LLVM 
client would have to translate to their own formats, like the garbage 
collection "unwind" tables. If that's too complicated at least it
would
be nice to supply custom filter functions for catch clauses. Inspired 
by SEH filters obviously, but we might devise a slightly more portable 
version.

Even for C++ I actually wouldn't mind being able to arbitrarily replace 
the personality, and/or the runtime functions for throwing and 
resuming. In my C++ source code I always throw exceptions wrapped in a 
macro, because I want to instrument all my throw statements. In 
particular, I can construct a reliable stack trace on the spot with 
RtlVirtualUnwind (or walking the EBP chain on x86). It would be a nice 
bonus if we could implement this kind of instrumentation with Clang. 
Encouragement to switch from MSVC :)

Steve

On Mon, May 18, 2015 at 2:42 PM, Steve Cheng <steve.ckp at gmail.com>
wrote:
> Hi Reid,
>
>  Right, __CxxFrameHandler3 is a lot more constraining than
>> __C_specific_handler. The SEH personality doesn't let you rethrow
>> exceptions, so once you catch the exception you're done, you're
in the
>> parent function. My understanding is that C++ works by having an active
>> catch handler on the stack.
>>
>
> Okay, I checked the Wine source code for __CxxFrameHandler3. I stand
> corrected.
>
> While we are on the topic of Windows EH, I like to know your (and
others',
> of course) thoughts on the following. It's my wishlist as a frontend
> implementor :)
>
> - Win32 (x86) frame-based SEH
>
> For __CxxFrameHandler3, since destructors and catch blocks execute as
> funclets while the throwing function's stack frame is still active,
it's
> not going to be a problem right?
>
My understanding is that __CxxFrameHandler3 does something like the
following:

for (void (*Cleanup)(bool, void*) : Cleanups) {
  __try {
    Cleanup(/*AbnormalTermination=*/true, EstablisherFrame);
  } __except(1) {
    std::terminate(); // can't rethrow
  }
}
__try {
  CallCatchBlock();
} __except(__CxxDetectRethrow(), EXCEPTION_CONTINUE_SEARCH) {
}

So I guess it's not really that the catch block has an active frame, and
more that __CxxFrameHandler3 is there saying "hey, I saw a rethrow
exception go by during phase 1, here's what that exception was supposed to
be".

But for __C_specific_handler, I see a potential issue versus x86-64,
in
> that RtlUnwind can't restore non-volatile registers, so when registers
are
> garbage when control is transferred to the landing pad.  When I read the
> Itanium ABI documentation, it says that landing pads do get non-volatile
> registers restored, so I guess that's probably the working assumption
of
> LLVM.
>
That's pretty frustrating, given that the xdata unwinder already knows
where the non-volatile registers are saved. Anyway, I think it can be
overcome in the backend with the right register allocation constraints.

> __C_specific_handler's registration frame saves down EBP, but no other
> registers, even ESP. If we use dynamic alloca or frame pointer omission, we
> are dead in the water, right?
>
Are you sure the unwinder doesn't restore RSP? Anyway, the address of a
dynamic alloca can easily be spilled to the stack and reloaded.

> - Writing one's own personality functions
>
> This makes a lot of sense if one is implementing a different language than
> C++ that has exceptions, and is prepared to provide their own run-time
> support.
>
> Say, if the language supports resuming from exceptions, or can query type
> information in more flexible ways than C++'s std::type_info matching.
Does
> it really make sense for the backend, LLVM, to hard-code knowledge about
> the language-specific data area (LSDA)? Even in the Itanium ABI it's
> explicitly stated that the personality is specific to the source language,
> yet multiple personalities can interoperate in the same program. Ideally, I
> would prefer the backend to take control of everything to do with arranging
> the landing pads, branches within landing pads, and so on, but NOT the
> language-dependent exception matching.
>
> Taken to the extreme, LLVM would have to expose tables that the LLVM
> client would have to translate to their own formats, like the garbage
> collection "unwind" tables. If that's too complicated at
least it would be
> nice to supply custom filter functions for catch clauses. Inspired by SEH
> filters obviously, but we might devise a slightly more portable version.
>
I think LLVM has to know about the table format and landingpad PC values,
because that's its business. The RTTI data, though, is completely between
the frontend and the EH personality. I could imagine a personality that
uses an Itanium LSDA, but the RTTI pointers are really pointers to
functions that get called during phase 1 to implement SEH filters. The new
representation will actually allow you to pass more data here to support
passing in "adjectives" as required for MSVC, but LLVM will have to
know
where to put it in the table and there's no way to avoid that.

> Even for C++ I actually wouldn't mind being able to arbitrarily replace
> the personality, and/or the runtime functions for throwing and resuming. In
> my C++ source code I always throw exceptions wrapped in a macro, because I
> want to instrument all my throw statements. In particular, I can construct
> a reliable stack trace on the spot with RtlVirtualUnwind (or walking the
> EBP chain on x86). It would be a nice bonus if we could implement this kind
> of instrumentation with Clang. Encouragement to switch from MSVC :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/4088f1e0/attachment.html>