[llvm-commits] [Patch] Exception Handling Documentation

[Bill Wendling]

On Aug 2, 2011, at 6:38 PM, John McCall wrote:
> On Aug 2, 2011, at 2:29 PM, Bill Wendling wrote:
>> On Aug 2, 2011, at 1:24 PM, Chris Lattner wrote:
>>> <h5>Arguments:</h5>
>>> -<p>The '<tt>resume</tt>' instruction's argument must have the same type as the
>>> -   result of any '<tt>landingpad</tt>' instruction in the same function.</p>
>>> +<p>The '<tt>resume</tt>' instruction requires one argument, which must have the
>>> +   same type as the result of any '<tt>landingpad</tt>' instruction in the same
>>> +   function.</p>
>>> 
>>> Thanks for mentioning this.  As a devil's advocate question: shouldn't this be forced to match the landingpad instruction that interrupted the unwind?  isn't it theoretically possible to have code like this:
>>> 
>>> 
>>> invoke @somefunc  -> unwind %landingpadbb
>>> 
>>> landingpadbb:
>>> %A = landingpad ...
>>> call foo(%A)
>>> unreachable
>>> 
>>> void foo( ... %A) {
>>> resume %A
>>> }
>>> 
>>> In other words, does the resume actually have to be in the same function as the landing pad?
>>> 
>> Interesting. No, it doesn't need to be in the same function.
> 
> 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:

* The call to a function containing the _Unwind_Resume (foo here) is made.
* The _Unwind_Resume is called with the existing exception.
* The stack resumes unwinding from "foo".
* The place where "foo" was called will have an entry in the LSDA (typically saying it can't catch anything and has no landing pad).
* The exception will continue from the "foo" call-site.

This is not to say that an existing implementation won't subvert this somehow. But it's hypothetically okay to do this. Consider that the _Unwind_Resume function may (and indeed does) call other functions itself before the exception is resumed (deep within the call stack), then you have an analogous situation.

Perhaps we could list this as an "okay to do, but not advised" feature?

-bw