llvm dev - Sep 2011 - [LLVMdev] How to code catch-all in the new exception handling scheme?

I'm looking at the docs, and while it refers to a "catch-all"
clause, it
doesn't describe how to construct one. In the old scheme, a selector value
of 0 was used. What's the corresponding technique for the new scheme? Do I
need to update my personality function to handle catch-alls (it wasn't
needed in the previous scheme)?

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110924/6e622b2a/attachment.html>

Hi Talin,
> I'm looking at the docs, and while it refers to a "catch-all"
clause,
hopefully Bill will get rid of the first reference to "catch-all"
since
that section is inaccurate.

  it doesn't
> describe how to construct one.
There is in general no such thing as a catch-all: it depends on the personality
function (i.e. the language), and, for example, the Ada language doesn't
have
one (it has something that catches all Ada exceptions, but it won't catch
C++
exceptions).

  In the old scheme, a selector value of 0 was
> used.
Technically speaking that's a cleanup not a catch-all.  C++ illustrates the
difference: if you throw an exception in a C++ program that only has cleanups
then the exception won't be unwound, instead the C++ unwinder code will just
terminate your program; however if there is a C++ catch-all (represented by
a catch with a null pointer in LLVM) then the exception will be unwound and
the landing pad branched to in the expected way.  The C++ catch-all is
represented by a catch clause with a null pointer argument in LLVM, but this
is C++ specific.  Note that the cleanup behaviour I mentioned is somewhat
built into the GCC unwinding library: when you call _Unwind_RaiseException,
if the search phase discovers that nothing matches the exception except for
cleanups all the way up the stack, then the call to _Unwind_RaiseException
returns (otherwise control branches to the landing pad that matched the
exception).  If you want cleanups to be run anyway, then you need to call
_Unwind_ForcedUnwind if _Unwind_RaiseException returns.  This is in contrast
to what happens if there is a catch-all: the call to _Unwind_RaiseException
will see that the exception matches the catch-all (because the personality
function says so) and it will cause execution to resume at the corresponding
landing pad.

  What's the corresponding technique for the new scheme?

To get a cleanup add the "cleanup" flag to the landingpad instruction.
That
said, I'm ruminating on whether the cleanup flag should be removed: instead
there would always be an implicit cleanup.  As an optimization, the code
generators would not output a cleanup into the exception handling tables if
no useful code is executed when the cleanup is run.  This seems to be what
recent versions of GCC do.

  Do I need to update
> my personality function to handle catch-alls (it wasn't needed in the
previous
> scheme)?
Ciao, Duncan.

On Sep 25, 2011, at 1:02 AM, Duncan Sands wrote:
> Hi Talin,
> 
>> I'm looking at the docs, and while it refers to a
"catch-all" clause,
> 
> hopefully Bill will get rid of the first reference to "catch-all"
since
> that section is inaccurate.
> 
I *think* this is now correct. Please check. :)
> it doesn't
>> describe how to construct one.
> 
> There is in general no such thing as a catch-all: it depends on the
personality
> function (i.e. the language), and, for example, the Ada language
doesn't have
> one (it has something that catches all Ada exceptions, but it won't
catch C++
> exceptions).
> 
This is true in a sense that a catch-all is encoded the same way as any other
catch type. So for C++, you would specify a catch-all like this:

 %exn = landingpad { i8*, i32 } personality i32 (...)* __gxx_personality_v0
           catch i8* @_ZTIi
           catch i8* null

A 'null' value is C++'s way of saying "this is a
catch-all". Ada uses a global variable (function?) for this. To the new EH
scheme, they are indistinguishable from a "normal" catch.
> To get a cleanup add the "cleanup" flag to the landingpad
instruction.  That
> said, I'm ruminating on whether the cleanup flag should be removed:
instead
> there would always be an implicit cleanup.  As an optimization, the code
> generators would not output a cleanup into the exception handling tables if
> no useful code is executed when the cleanup is run.  This seems to be what
> recent versions of GCC do.
> 
I'm not a big fan of implicit behavior. :) And it requires an optimization
to "cleanup" (yeah, a pun...sue me) the extraneous code we generate,
which won't happen at -O0 (right?). Though the optimization you mentioned
here would be a nice thing to have with our current scheme.

-bw