Unwind API for EH

[Eli Boling]

I actually prefer the SetGR interface.  The reason is this:  The current unwind
ABI can be changed with relative ease to support IA32, as well as IA-64.  This
is helped by the current form of SetGR.

-Eli

Cary Coutant wrote:

> 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