Unwind API for EH

[Jim Dehnert]

OK, let's see if we can reach closure on this one.  I'll summarize the
situation...

We have three parties to the landing pad parameter passing:

  PR (personality routine) generates the values, passes them to
  UL (unwind library), which puts them where they are expected by
  LP (landing pad).

Now PR and LP need to know the semantics of the parameters, while
UL and LP need to know what registers they're in (UL only because it
needs to maintain space for them in its context record).  PR and LP are
generated by the same compiler/implementation, while UL may come
from a different implementation.

The current interface definition adds the requirement that PR know which
registers to use as well.

Cary's proposal would remove this additional knowledge in PR (but not
in LP, produced by the same implementation), with the benefit that PR
could be somewhat less target-specific, and the PR-UL interface is
trivially extensible to a different number of parameters (though the
current interface just requires more or fewer _Unwind_SetGR calls).

Personally, I think Cary's interface is marginally cleaner, but not
significantly.  Given how late this is in the process, and the base
psABI impact of a change, (and significant non-concensus,) I think it's
better left as the status quo.  Does anyone have a major problem with
this?

However, the discussion does point out that the LP registers should be
clearly identified in the ABI as the _only_ scratch registers that must
be supported in the context.  Right?

Jim

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