[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

[Kenneth Uildriks]

They require multiple stages of unwind.  Basically any call inside a
"try" block needs to be an invoke.  Unwind would go to the lowermost
invoke in the call stack, jump to the handler and the handler, if
appropriate, would issue another unwind.

A function with stack-allocated objects having non-trivial destructors
in C++ would work the same way.  Unwind would skip any functions that
don't need cleanup, go to the cleanup code within functions that do,
and that cleanup code would issue another unwind to continue the
process.

On Mon, Jul 20, 2009 at 7:38 AM, Nick
Johnson<nicholas.paul.johnson at gmail.com> wrote:
>> In languages without stack-allocated objects (ie. most languages that
>> support exceptions) there is no need to unwind frame-by-frame, the
>> unwind simply needs to make a single jump to the invoke instruction and
>> restore the context (which in x86 is just 6 registers).
>>
>
> No.  Java, C#, Ruby and Python all support the finally/ensure block;
> C# supports the using( IDisposable x =...) {} construct.  Both
> constructs require support for a frame-by-frame unwind; as these
> construct can be nested, a single throw may visit many landing pads
> (which may come from different compilation units).
>
> It doesn't have anything to do with stack-allocated vs heap-allocated,
> but rather with the language's guarantees about exceptions.
>
>
>> It is possible to implement invoke/unwind in such a way that both invoke
>>  *and* unwind are fast, when  unwind just unwinds and doesn't perform
>> any magic behind-the-scenes operations.
>>
>
> Why?  Exceptions are supposed to occur in exceptional situations.  In
> general, one should try to optimize for the common case, which does
> not include invoke/unwind.
>
> One should certainly not slow down a function call which never throws
> just because other functions may throw.  Paraphrasing Bjarne
> Stroustrup, "If you don't use it, you shouldn't pay for it."
>
>
> Nick
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>