Unwind API for EH

[Cary Coutant]

I'd like to propose a small change to the Unwind API used for EH.

>void _Unwind_SetGR
>   (struct _Unwind_Context *context,
>    int index,
>    uint64 new_value);
>
>This function sets the 64-bit value of the given register, identified by 
>its index as for _Unwind_GetGR. The NAT bit of the given register is reset.
>
>The behaviour is guaranteed only if the function is called during phase 2 
>of unwinding, and applied to an unwind context representing a handler 
>frame, for which the personality routine will return _URC_INSTALL_CONTEXT. 
>In that case, only registers GR15, GR16, GR17, GR18 should be used. These 
>scratch registers are reserved for passing arguments between the 
>personality routine and the landing pads.

The _Unwind_SetGR function is used to setup the landing pad arguments, 
but I believe this interface is too general. If we don't restrict this 
API to r15-r18, the unwind library needs to be prepared to deal with 
requests to set arbitrary scratch registers in the unwind context record. 
Ordinarily, the unwind context wouldn't need to have scratch registers at 
all. By restricting this API to r15-r18, and to the specific uses 
mentioned, however, we've ended up architecting the landing pad registers 
after all -- which was what we were trying to avoid in defining the 
general interface.

Thus, I believe that the landing pad arguments should be communicated by 
a more specific interface, something like this:

void _Unwind_SetLPArgs
   (struct _Unwind_Context *context,
    int nargs,
    uint64 *args);

Registers 15-18 will be architected to be used for these registers, and 
it will be the unwind library's responsibility to place the landing pad 
arguments in the right registers when it installs the context.

The interface is extensible in case we architect more than 4 registers 
for landing pad arguments, but the implementation doesn't need to support 
more than 4 until such time as the architecture is changed.

I still believe that _Unwind_SetGR has its uses, though -- just not for 
scratch registers, which shouldn't even be kept in the unwind context, 
and not for EH. As such, it doesn't need to be in the C++ EH ABI paper. I 
think this will allow us to provide a much cleaner definition of 
_Unwind_SetGR, though, for debuggers and the like where it is useful as a 
general-purpose routine.

-cary