[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