[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

[Vadim Chugunov]

Hi Reid,
Is this design supposed to be able to cope with asynchronous exceptions?
I am having trouble imagining how this would work without adding the
ability to associate landing pads with scopes in LLVM IR.

Vadim


On Tue, Nov 25, 2014 at 5:27 PM, Reid Kleckner <rnk at google.com> wrote:

> On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
> wrote:
>
>>  > We should also think about how to call std::terminate when cleanup
>> dtors throw. The current representation for Itanium is inefficient. As a
>> strawman, I propose making @__clang_call_terminate an intrinsic:
>>
>> …
>>
>>
>>
>> That sounds like a good starting point.
>>
>>
>>
>>
>>
>> > Chandler expressed strong concerns about this design, however, as
>> @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once you
>> add this intrinsic, we *have* to do frame layout of @_Z13do_some_thingRi
>> *before* we can emit code for all the callers of
>> @llvm.eh.get_capture_block. Today, this is easy, because module order
>> defines emission order, but in the great glorious future, codegen will
>> hopefully be parallelized, and then we've inflicted this horrible
>> constraint on the innocent.
>>
>>
>>
>> > His suggestion to break the ordering dependence was to lock down the
>> frame offset of the capture block to always be some fixed offset known by
>> the target (ie ebp - 4 on x86, if we like that).
>>
>>
>>
>> Chandler probably has a better feel for this sort of thing than I do.  I
>> can’t think of a reason offhand why that wouldn’t work, but it makes me a
>> little nervous.
>>
>>
>>
> What would that look like in the IR?  Would we use the same intrinsics and
>> just lower them to use the known location?
>>
>
> Chandler seems to be OK with get/set capture block, as long as the codegen
> ordering dependence can be removed. I think we can remove it by delaying
> the resolution of the frame offset to assembly time using an MCSymbolRef.
> It would look a lot like this kind of assembly:
>
> my_handler:
>   push %rbp
>   mov %rsp, %rbp
>   lea Lframe_offset0(%rdx), %rax ; This is now the parent capture block
>   ...
>   retq
>
> parent_fn:
>   push %rbp
>   mov %rsp, %rbp
>   push %rbx
>   push %rdi
>   subq $NN, %rsp
> Lframe_offset0 = X + 2 * 8 ; Two CSRs plus some offset into the main stack
> allocation
>
> I guess I'll try to make that work.
>
> I’ll think about this, but for now I’m happy to just proceed with the
>> belief that it’s a solvable problem either way.
>>
>>
>>
>> >> For C++ exception handling, we need cleanup code that executes before
>> the catch handlers and cleanup code that excutes in the case on uncaught
>> exceptions.  I think both of these need to be outlined for the MSVC
>> environment. Do you think we need a stub handler to be inserted in cases
>> where no actual cleanup is performed?
>>
>> > I think it's actually harder than that, once you consider nested trys:
>>
>> > void f() {
>>
>> >  try {
>>
>> >    Outer outer;
>>
>> >    try {
>>
>> >      Inner inner;
>>
>> >      g();
>>
>> >    } catch (int) {
>>
>> >      // ~Inner gets run first
>> >    }
>>
>> >  } catch (float) {
>>
>> >    // ~Inner gets run first
>>
>> >    // ~Outer gets run next
>> >  }
>>
>> >  // uncaught exception? Run ~Inner then ~Outer.
>> > }
>>
>>
>>
>> I took a look at the IR that’s generated for this example.  I see what
>> you mean.  So there is potentially cleanup code before and after every
>> catch handler, right?
>>
>>
>>
>> Do you happen to know offhand what that looks like in the .xdata for the
>> _CxxFrameHandler3 function?
>>
>
> I can't tell how the state tables arrange for the destructors to run in
> the right order, but they can accomplish this without duplicating the
> cleanup code into the outlined catch handler functions, which is nice.
>
> I think we may be able to address this by emitting calls to start/stop
> intrinsics around EH cleanups, but that may inhibit optimizations.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141202/decb0a15/attachment.html>