Re: [PATCH] mips: Fix store/load gp registers to/from ucontext_t

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Thu, 18 May 2017, Joseph Myers wrote:

> >  Not according to SUSv2 [1] AFAICT:
> > 
> > "The setcontext() function restores the user context pointed to by ucp.  
> > A successful call to setcontext() does not return; program execution 
> > resumes at the point specified by the ucp argument passed to setcontext().  
> > The ucp argument should be created either by a prior call to getcontext() 
> > or makecontext(), or by being passed as an argument to a signal handler."
> > 
> > -- notice the last statement.
> 
> Note that it says what the semantics are "If the ucp argument was created 
> with getcontext()" and "If the ucp argument was created with 
> makecontext()".  It does *not* say what the semantics are if it came from 
> a signal handler; they are unspecified.  That is, SUSv2 deliberately 
> removed the (presumably problematic) specification from XPG4.2 about the 
> results "If the ucp argument was passed to a signal handler".

 Indeed, XPG4.2 has this clause:

"If the ucp argument is passed to a signal handling routine, the program 
execution is continued with the next instruction after the one interrupted 
by the signal."

(quoted from a secondary reference; is there any proper online source for 
XPG4.2 itself?), which is not there in SUSv2.

 However as previously quoted and retained above in the SUSv2 
specification of `setcontext' a more general statement applies:

"A successful call to setcontext() does not return; program execution 
resumes at the point specified by the ucp argument passed to 
setcontext()."

which I interpret that with `ucp' passed as an argument to a signal 
handler and then used with `setcontext':

1. The call does not return.

2. The contents of `ucp' determine the point of resumption, which however 
   is not further specified by SUSv2.

-- as long as the call is successful.  So I wouldn't say the results of 
such a call are unspecified, but rather that they are not as strictly 
specified (as far as the exact point of resumption is concerned) as with 
`ucp' obtained with `getcontext' or created by `makecontext'.

 I suspect that the rationale behind the removal from SUSv2 of the XPG4.2 
requirement for execution to continue "with the next instruction after the 
one interrupted by the signal" is that due to how hardware has been 
designed in many systems `ucp' passed as an argument to a signal handler 
will for signals like SIGILL hold a value of the PC that points to the 
instruction interrupted by the signal itself rather than the next one, 
causing it to vary from signal to signal and making it potentially very 
difficult for a hypothetical fully XPG4.2-conformant `setcontext' to 
implement.

 However I think that this does not give us a freedom, having opted in to 
implement this feature set, to arbitrarily decide to make `setcontext' 
(and consequently `swapcontext') behave in a random manner when given 
`ucp' passed as an argument to a signal handler.  It is still supposed to 
resume according to the contents of `ucp'.  And this is what my original 
MIPS implementation was intended to do, using the signal-specific value of 
PC held in `ucp' upon the entry to a signal handler.

 One could argue that SUSv2 does not specify the conditions for a 
`setcontext' call to be successful or not in the first place, so in 
principle it looks to me that a system may be defined such that any such 
call may fail, perhaps for any `ucp' passed to a signal handler as opposed 
to having been obtained with `getcontext' or created by `makecontext'.  
In reality there may be no way to tell them apart though, and IIRC in my 
implementation this is the case except where DSP registers have been 
included by the kernel in `ucp' passed as an argument to a signal handler 
(so not in the general case).  To say nothing of whether there is actually 
any sense in deliberately failing all such `setcontext' calls.

 Thoughts?

  Maciej