DragonFlyBSD

This issue was brought to light with respect to some recent
interactions with sysmouse & xf86-input-mouse > v1.2.1
(see #871, users@ list ~2007-11-08) as well as

http://mail-index.netbsd.org/pkgsrc-users/2007/08/06/0008.html

Matt States:

Should we start saving and restoring the FP context? The ucontext
structure does have enough space reserved for it. During the LWP
work we expanded the FP save space to 512 bytes.

Basically code would have to be added to sendsig() and sigreturn().

sendsig():

• Check if the FP is used by the process. If not, nothing
  to do.
• If it is, but it isn't active, copy the saved state to the
  ucontext
• If it is, and it is currently active, save the current state
  to the ucontext.
• Set flags in ucontext appropriately to indicate that the FP
  state has been saved.
• If ucontext has flagged that it holds FP state, restore the FP
  tate from the ucontext.

sigreturn():

Nuno Antunes pointed out a regression test in OpenBSD's tree:

http://www.openbsd.org/cgi-bin/cvsweb/src/regress/sys/kern/signal/fpsig/

I took a crack at implementing this but couldn't figgure enough about
how the stack & registers are mapped out to implement according to above..

some notes:

/usr/src/sys/platform/pc32/i386/machdep.c:
- sendsig:
- sys_sigreturn:

./sys/sys/ucontext.h:
typedef struct __ucontext {
...
mcontext_t uc_mcontext;
...

where:

./sys/cpu/i386/include/ucontext.h:
has the various register's +=
int mc_fpregs¹²⁸; /* full fp state */
int spare[16];
which I believe matt was referring to above..
along with:

#define _MC_FPOWNED_NONE        0x20000 /* FP state not used /
     #define _MC_FPOWNED_FPU         0x20001 / FP state came from FPU /
     #define _MC_FPOWNED_PCB         0x20002 / FP state came from PCB */

which as I recall are used in the function calls above.

perhaps I'll take another crack at it soon, in the meantime,
perhaps this might help someone else.

As a side note, posix doesn't seem to mention this definitively one way
or another - due to the possiblility of SIGFPE occurring within a
handler I'm not sure that it's the wisest thing to do in the first
place.. It might be worth considering if the potential dropped signals
resulting from SIGFPE in an implementation of this fix.