C++ EH vs Forced Unwinding, Round 3

[Richard Henderson <rth at redhat dot com>]

Ok, so I've been looking at making catch(...) do what the majority of
folks here think it should.  In the process I've fixed a whole raft of
bugs in libstdc++ wrt the handling of foreign exceptions.

However, there's still a problem.  The following test case fails:

----------------------------------------------------------------------
// { dg-do run }

// Test that forced unwinding runs all cleanups.  Also tests that
// rethrowing doesn't call the exception object destructor.

#include <unwind.h>
#include <stdlib.h>

static int test = 0;

static _Unwind_Reason_Code
force_unwind_stop (int version, _Unwind_Action actions,
                   _Unwind_Exception_Class exc_class,
                   struct _Unwind_Exception *exc_obj,
                   struct _Unwind_Context *context,
                   void *stop_parameter)
{
  if (actions & _UA_END_OF_STACK)
    {
      if (test != 15)
        abort ();
      exit (0);
    }

  return _URC_NO_REASON;
}

static void
force_unwind_cleanup (_Unwind_Reason_Code, struct _Unwind_Exception *)
{
  abort ();
}

static void force_unwind ()
{
  _Unwind_Exception *exc = new _Unwind_Exception;
  exc->exception_class = 0;
  exc->exception_cleanup = force_unwind_cleanup;

#ifndef __USING_SJLJ_EXCEPTIONS__
  _Unwind_ForcedUnwind (exc, force_unwind_stop, 0);
#else
  _Unwind_SjLj_ForcedUnwind (exc, force_unwind_stop, 0);
#endif

  abort ();
}

struct S
{
  int bit;
  S(int b) : bit(b) { }
  ~S() { test |= bit; }
};
  
static void doit ()
{
  try {
    S four(4);

    try {
      S one(1);
      force_unwind ();
  
    } catch(...) { 
      test |= 2;
      throw;
    }

  } catch(...) {
    test |= 8;
    throw;
  }
}

int main()
{ 
  doit ();
  abort ();
}
----------------------------------------------------------------------

It fails because the rethrow from the last catch clause can't find a
handler in an outer scope, and by C++ rules, calls std::terminate.

In effect, the transition to the catch clause usurped control from
_Unwind_ForcedUnwind, and so we no longer have force_unwind_stop to
tell us to exit cleanly when we get to the top of the stack.

The reason we didn't see this with just destructors is that they use
_Unwind_Resume instead of __cxa_rethrow.  The reason for this difference
is buried in real semantic differences between the two concepts in the
C++ library standard.

This is not just a failure within a contrived test case.  In real
life libpthread will have to check for C stack frames with registered
setjmp cleanups, and run them in the proper order.  (It may or may not
be appropriate at this point to plug the try/finally patches posted
last fall, which were rejected.)

This is not fixable within the ABI defined for the unwind library.

There is a *possible* hack that could be employed that would work
with gcc's implementation, but it wouldn't necessarily work with
another from-spec implementation.

We could extend the ABI yet again and hope that HPUX picks it up;
until they do, ia64-hpux will be broken.  (Well, we could add some
ifdef hackery which would bandage enough for normal c++ usage, 
but anything that uses _Unwind_ForcedUnwind won't work right.)

It's clear to me that no one had any real-life experience with the
less-used parts of IA-64 EH ABI when it was designed and deployed.

Anyway, I guess I'll go ahead with the ABI change, since I bet
none of you are willing to budge on catch(...).  More to come.


r~