Bug #875

Add FPU state to signal handler context

Added by c.turner almost 7 years ago. Updated over 6 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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.

sigreturn():
* If ucontext has flagged that it holds FP state, restore the FP
tate from the ucontext.

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[128]; /* 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.

History

#1 Updated by dillon almost 7 years ago

: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:

I'll take a crack at it right now.

-Matt

Also available in: Atom PDF