[llvm-commits] [Patch] Exception Handling Documentation

Bill Wendling wendling at apple.com
Wed Aug 3 10:12:21 PDT 2011


On Aug 3, 2011, at 12:12 AM, John McCall wrote:
> 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.
> 
It's more of a philosophical issue. LLVM's IR has always been flexible enough that you should be able to take some basic blocks and make a function out of them without changing the semantics of the program.[1] I'm assuming that this is why Chris asked this question. The value would be in having one less restriction on the IR. I like restrictions, but only if they are 100% necessary.

-bw

[1] Not 100% true (e.g., invoke), but close to true for most LLVM IR instructions.




More information about the llvm-commits mailing list