This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] mips: Fix store/load gp registers to/from ucontext_t
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