[llvm-commits] [llvm] r140128 - /llvm/trunk/docs/ExceptionHandling.html

[Bill Wendling]

On Sep 20, 2011, at 1:18 AM, Duncan Sands wrote:

> Hi Bill,
> 
>> +<p>The<tt>landingpad</tt>  instruction takes a reference to the personality
>> +   function to be used for this<tt>try</tt>/<tt>catch</tt>  sequence. The
>> +   remainder of the instruction is a list of<i>catch</i>  and<i>filter</i>
>> +   clauses. The exception is tested against the clauses sequentially from first
>> +   to last. The selector value is a positive number if the exception matched a
>> +   type info, a negative number if it matched a filter, and zero if it matched a
>> +   cleanup. If nothing is matched, the behaviour of the program
>> +   is<a href="#restrictions">undefined</a>.
> 
> woah!  In order to have inlining work, the LLVM IR that compares the selector
> value with catches (via llvm.eh.typeid.for) needs to call "resume" if nothing
> matches.  So I think it would be better to say that if an exception doesn't
> match a catch or filter, then control might still get here but with a selector
> value that doesn't correspond to any of the catches/filters in the landingpad
> instruction.  That automatically forces people to do a "resume" if the selector
> doesn't match any of their catches.  And this is what happens if the landingpad
> is inlined into another function: if there are some additional catches in the
> caller, then they get appended to the landingpad instruction, which means that
> you can get the selector value for them even though in the original landing pad
> that value didn't correspond to any of the catches/filters.
> 
Hang on. That was from the original doc. :) I'll update it appropriately.

>   Each of these functions requires a reference to the
>> +   exception structure.  Note that the most general form of a
>> +<a href="LangRef.html#i_landingpad"><tt>landingpad</tt>  instruction</a>  can
>> +   have any number of catch, cleanup, and filter clauses (though having more
>> +   than one cleanup is pointless).
> 
> As there is now only a cleanup flag, you can't have multiple cleanup "clauses".
> 
I thought about that, and yeah. Though you could potentially write something like this:

	landingpad { i8*, i32 } personality ...
          cleanup
          catch i8* @_ZTIi
          cleanup

and it would still work and be just as pointless.

>  The LLVM C++ front-end can generate such
>> +<a href="LangRef.html#i_landingpad"><tt>landingpad</tt>  instructions</a>  due
>> +   to inlining creating nested exception handling scopes.</p>
>> 
>>  </div>
>> 
>> @@ -377,29 +360,27 @@
>> 
>>  <div>
>> 
>> -<p>The unwinder delegates the decision of whether to stop in a call
>> -   frame to that call frame's language-specific personality function.
>> -   Not all personalities functions guarantee that they will stop to
>> -   perform cleanups: for example, the GNU C++ personality doesn't do
>> -   so unless the exception is actually caught somewhere further up the
>> -   stack.  When using this personality to implement EH for a language
>> -   that guarantees that cleanups will always be run, be sure to
>> -   indicate a catch-all in the
>> -<a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>  call
>> +<p>The unwinder delegates the decision of whether to stop in a call frame to
>> +   that call frame's language-specific personality function.  Not all
>> +   personalities functions guarantee that they will stop to perform
>> +   cleanups. For example, the GNU C++ personality doesn't do so unless the
>> +   exception is actually caught somewhere further up the stack.
> 
> Here I think it would be good to make clear that in this case the program
> exits with a called to terminate - the stack isn't unwound at all (well,
> the unwinder crawls up the stack in the search phase but no more than that).
> 
>   When using this
>> +   personality to implement EH for a language that guarantees that cleanups will
>> +   always be run, be sure to indicate a catch-all in the
>> +<a href="LangRef.html#i_landingpad"><tt>landingpad</tt>  instruction</a>
>>     rather than just cleanups.</p>
> 
> Ada uses forced unwinding rather than catch-alls to get this effect.  I suggest
> just dropping this bit of advice.
> 
Okay.

>> 
>> -<p>In order for inlining to behave correctly, landing pads must be
>> -   prepared to handle selector results that they did not originally
>> -   advertise.  Suppose that a function catches exceptions of
>> -   type<tt>A</tt>, and it's inlined into a function that catches
>> -   exceptions of type<tt>B</tt>.  The inliner will update the
>> -   selector for the inlined landing pad to include the fact
>> -   that<tt>B</tt>  is caught.  If that landing pad assumes that it
>> -   will only be entered to catch an<tt>A</tt>, it's in for a rude
>> -   surprise.  Consequently, landing pads must test for the selector
>> -   results they understand and then resume exception propagation
>> -   with the<a href="#llvm_eh_resume"><tt>llvm.eh.resume</tt></a>
>> -   intrinsic if none of the conditions match.</p>
>> +<p>In order for inlining to behave correctly, landing pads must be prepared to
>> +   handle selector results that they did not originally advertise.
> 
> Right!
> 
>   Suppose that
>> +   a function catches exceptions of type<tt>A</tt>, and it's inlined into a
>> +   function that catches exceptions of type<tt>B</tt>.  The inliner will update
>> +   the<tt>landingpad</tt>  instruction for the inlined landing pad to include
>> +   the fact that<tt>B</tt>  is caught.  If that landing pad assumes that it will
>> +   only be entered to catch an<tt>A</tt>, it's in for a rude surprise.
>> +   Consequently, landing pads must test for the selector results they understand
>> +   and then resume exception propagation with the
>> +<a href="LangRef.html#i_resume"><tt>resume</tt>  instruction</a>  if none of
>> +   the conditions match.</p>
> 
> Nice explanation.
> 
Thanks! I wish I could take credit for it. :-)

-bw