gcc unwind ABI change for forced unwind

[Jason Merrill]

On Wed, 21 May 2003 15:00:30 -0700, Cary Coutant <cary at cup.hp.com> wrote:

> As I understand the central issue, we would like to run C++ cleanups on a
> thread cancellation, in addition to the cleanups registered through the
> POSIX C bindings to the pthreads library.

Yes.

> Cleanups resulting from local automatic objects that need destruction are
> easy, but the problem is what to do about catch(...) blocks. Richard's
> approach was to end such blocks with a call to the new API,
> "_Unwind_Resume_or_Rethrow()", if the block did not already end with a
> rethrow.

Rather, a rethrow at the end of a catch(...) block uses that API instead of
the usual rethrow code.  If the block doesn't end with a rethrow, nothing
is changed.

> I think Jason Merrill hit the nail on the head when he said (on 4/30):
>
>> The problem is that catch(...) is overloaded in C++.  It's used both for
>> code that wants to write a cleanup inline and rethrow and for code that
>> wants to trap all exceptions.
>
> There was some discussion about whether catch(...) blocks should run at all
> when doing a forced unwind, and whether forced unwinds should be allowed to
> penetrate a function declared throw(). I think I saw a consensus on the
> latter issue that thread cancellation and longjmp_unwind are not really
> exceptions, and must be allowed to proceed.

Actually, the consensus was that we should call terminate() if we try to
unwind through a throw().  Allowing it to go through would destroy the
optimization benefits of throw().

> On the former issue, however, there didn't seem to be a clear resolution.

Everyone agreed that we would like to be able to run cleanups; the problem
was telling them apart from other cases.

I came up with a solution: use terminate() as the destructor for the forced
unwind exception object.  That way, we can just run all catch(...) blocks.
If it rethrows, we continue to unwind normally, but if it exits some other
way, we try to destroy the exception object, which calls terminate().

Everyone seemed to like this solution for forced unwind.  The issue on
which there was disagreement was whether or not cancellation should be
treated like longjmp_unwind.  Several people argued that cancellation
should be a normal exception which can be caught and discarded.

Jason