[llvm-commits] [Patch] Exception Handling Documentation

John McCall rjmccall at apple.com
Wed Aug 3 00:12:47 PDT 2011


On Aug 2, 2011, at 11:48 PM, Bill Wendling wrote:
> On Aug 2, 2011, at 6:38 PM, John McCall wrote:
>> 
>> I don't think this is true;  the exceptions ABI strongly suggests that the
>> call to _Unwind_Resume should happen from the "landing pad", i.e.
>> from the function that unwinding stopped at.  I would not be surprised
>> if some existing implementations broke if you "outlined" the call to
>> _Unwind_Resume, and I certainly see no value in supporting it.
>> 
>> It should be undefined behavior to reach a resume and give it an
>> operand that does not correspond to the value of a landingpad
>> instruction from the same execution context.  (That's a dynamic
>> constraint about the data content of the value, not an SSA
>> constraint about the form of the operand).
>> 
> It strongly suggests, but it doesn't sound like a requirement to me. And after talking with Nick, I convinced myself that it is "okay" to have the _Unwind_Resume outside of the current function (I even did some tests). How he outlined it to me was:

I agree that this is likely to work with Darwin's libUnwind as long as the
LSDA doesn't indicate a cleanup for the call to calls_resume(), or that
landing pad doesn't lead to an outlined _Unwind_Resume call.  I am
less certain about SjLj unwinding, but it'll probably work there again.
I really see zero value in supporting this, though, and I do think it's
contrary to the intent of the ABI document.

John.



More information about the llvm-commits mailing list