Wrong wording in 1.3 "Throwing an exception."

[Jim Dehnert]

> From ddd at cup.hp.com Thu Oct  5 11:56:45 2000
> From: Christophe de Dinechin <ddd at cup.hp.com>
> 
> >  This call (to 
> > _Unwind_RaiseException) will happen in many places in compiled code
> 
> No, the actual call is to __cxa_throw or __cxa_rethrow, which itself
> calls _Unwind_RaiseException. This means that only __cxa_throw needs
> to care. What's more, it looks like:
> 
> 	_Unwind_RaiseException(...);
> 	// If it returns, we have no choice
> 	terminate();
> 
> There is little that could fail here, except failing to find the
> proper terminate handler (we need to have GP set right for that).
> The chances of having GP incorrect for the C++ runtime library and
> having anything else working is... low. So I would not care too much
> about that case.

OK.  I've rewritten it this way.

> >      c) Require that the unwinder also return valid GP for caller 
> > 	(and perhaps other registers).  (Remember that we've been 
> > 	modifying the context during phase 2 unwinding, so this 
> > 	probably requires extra work in the unwinder.) 
> 
> I believe this is not a problem: GP being used by the caller is not
> the GP set by the unwinder, but the GP as set before we called
> _Unwind_RaiseException. The GP is not set through stack unwinding
> but through dld.so generated stubs.

It's not so simple.  The stubs, if they modify GP, put the saved one
somewhere -- on the stack.  If the unwinder has unwound stack frames,
that in particular will be gone.  So instead, I expect that an error
return from _Unwind_RaiseException is going to, at best (depending on
how badly corrupted things have gotten) recover what it can (registers
and return address) from whatever context information it has saved
elsewhere.  The question is how much we will require it to get right,
keeping in mind that anything it is required to save other than in the
register context it needs for unwinding will cost time in all
exceptions for a presumably very rare case.  I'm inclined to require
that the GP and return value register be valid on return, and nothing
else.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272