[LLVMdev] Alternative exception handling proposal

[John McCall]

On Dec 3, 2010, at 9:08 AM, Duncan Sands wrote:
>>> Do you have an idea for how to keep catches etc out of the definition of the
>>> IR? I'm worried that if one day we add support for, say, SEH then we will
>>> have to change how the IR is defined again, and that's better avoided.
>>> 
>> I haven't given it a lot of thought. I don't like encoding DWARF-specific
>> concepts into the IR. But my proposal doesn't do that either. It involves
>> generic concepts that could be applied to all forms of EH.
> 
> I'm not sure they are generic.  Catches, cleanups, filters, typeinfos,
> personality functions - how generic are these?   I don't know enough about
> exception handling implementations on other platforms to say.

Well, even within DWARF EH, there are some things we'll never be able to
support without de-virtualizing LSDA layout;  we've just been lucky so far that
all the personality functions we care about supporting have very similar LSDA
structure.

In SEH-based C++ exceptions, try block handlers (i.e. catches) and unwind
actions (i.e. cleanups) are actually funclets.  A function with EH actions registers
itself with the runtime on entry.  As the function executes, it maintains an int
variable called the exception state.  A function wide-table has three subtables:
 - a list of RTTI pointers for the exception filter
 - a table, indexed by exception state, indicating the enclosing state and giving
   an optional funclet pointer for how to unwind out of that state
 - a list of try blocks, indicating the range of states they cover and giving a list
   of catch handlers, which are basically pairs of RTTI pointers and corresponding
   handler funclets that return the address to resume to.
I think we're not legally allowed to implement SEH, but if we were, there's a
surprisingly faithful lowering from Bill's dispatch instruction:
  - every landing pad is a state
  - the enclosing state is the state for the resume landing pad
  - if there's non-trivial code between the landing pad and the dispatch, it
    gets split out as the unwind funclet for that state
  - frontends would decorate branches out of the catch handler with some
    intrinsic call, and then we'd split out each catch handler as a funclet.

>> John all ready mentioned problems with your inlining proposal.
> 
> He seems to have changed his mind once I added in a small but important detail
> in my amendment (namely, that if an exception doesn't match the catches on an
> invoke, and the cleanup flag is not set, then it is unspecified as to whether
> it unwinds straight through the invoke, or branches to the landing pad).

For the record, I still prefer Bill's proposal;  I just think your revised proposal
is now viable.

John.