svn commit: r307971 - head/sys/mips/include

[John Baldwin]

On Friday, October 28, 2016 06:31:58 PM Konstantin Belousov wrote:
> On Thu, Oct 27, 2016 at 03:08:01PM -0700, John Baldwin wrote:
> > On Wednesday, October 26, 2016 05:37:08 PM John Baldwin wrote:
> > > Author: jhb
> > > Date: Wed Oct 26 17:37:08 2016
> > > New Revision: 307971
> > > URL: https://svnweb.freebsd.org/changeset/base/307971
> > > 
> > > Log:
> > >   Correct definition of 'struct sigcontext' on MIPS.
> > >   
> > >   Add missing fields ('sr' and 'mc_tls') to 'struct sigcontext'.
> > >   
> > >   The kernel doesn't use 'struct sigcontext' but instead uses 'ucontext_t'
> > >   which includes 'mcontext_t' in 'struct sigframe' to build the signal frame.
> > >   As a result, this change is not an ABI change but simply making
> > >   'struct sigcontext' correct.  Note that 'struct sigcontext' is only used
> > >   for "Traditional BSD style" signal handlers.
> > >   
> > >   While here, rename the 'xxx' field to '__spare__' to match 'mcontext_t'.
> > >   
> > >   Sponsored by:	DARPA, AFRL
> > 
> > We should perhaps a static assertion somewhere that
> > sizeof(sigset_t) + sizeof(ucontext_t) == sizeof(struct sigcontext) if
> > that is really true of all of our architectures.
> This should be mcontext_t instead of ucontext_t.

Yes.  I will try adding that static assert to sys/kern/kern_sig.c and
seeing if it survives a universe build.

> > Alternatively, we might consider retiring 'struct sigcontext' altogether.
> > It's purpose has been superseded by SA_SIGINFO (which is more portable)
> > which has been around for quite a while now.  As a first step I guess
> > we could try an exp-run with 'struct sigcontext' removed.  (We should
> > have ditched this in 5.0 since we have a separate sendsig/sigreturn path
> > for FreeBSD 4.x already.  Oh well.)
> 
> I do not think that this is a practical option. I know that struct
> sigcontext is used by nongnu libunwind. Quick search identifies mono and
> go as consumers as well.

Well, we could perhaps patch those to use SA_SIGINFO instead, but if it's
a non-trivial amount of effort I'm not going to bother.  I'm surprised that
some of those would use sigcontext.  Both mono and go post-date SA_SIGINFO
being standardized and supported on FreeBSD AFAIK.  Supporting sigcontext
just means extra BSD-specific code in those applications compared to using
SA_SIGINFO. :-/

-- 
John Baldwin