This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

C++ EH vs Forced Unwinding, Round 3

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;

  _Unwind_ForcedUnwind (exc, force_unwind_stop, 0);
  _Unwind_SjLj_ForcedUnwind (exc, force_unwind_stop, 0);

  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;

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]