[Midnightbsd-cvs] src [7976] trunk/sys/i386/isa/npx.c: stop clearing x87 exceptions in the mF handler on i386
laffer1 at midnightbsd.org
laffer1 at midnightbsd.org
Thu Sep 15 04:18:37 EDT 2016
Revision: 7976
http://svnweb.midnightbsd.org/src/?rev=7976
Author: laffer1
Date: 2016-09-15 04:18:36 -0400 (Thu, 15 Sep 2016)
Log Message:
-----------
stop clearing x87 exceptions in the mF handler on i386
Modified Paths:
--------------
trunk/sys/i386/isa/npx.c
Modified: trunk/sys/i386/isa/npx.c
===================================================================
--- trunk/sys/i386/isa/npx.c 2016-09-15 08:18:05 UTC (rev 7975)
+++ trunk/sys/i386/isa/npx.c 2016-09-15 08:18:36 UTC (rev 7976)
@@ -583,21 +583,21 @@
};
/*
- * Preserve the FP status word, clear FP exceptions, then generate a SIGFPE.
+ * Read the FP status and control words, then generate si_code value
+ * for SIGFPE. The error code chosen will be one of the
+ * FPE_... macros. It will be sent as the second argument to old
+ * BSD-style signal handlers and as "siginfo_t->si_code" (second
+ * argument) to SA_SIGINFO signal handlers.
*
- * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now
- * depend on longjmp() restoring a usable state. Restoring the state
- * or examining it might fail if we didn't clear exceptions.
+ * Some time ago, we cleared the x87 exceptions with FNCLEX there.
+ * Clearing exceptions was necessary mainly to avoid IRQ13 bugs. The
+ * usermode code which understands the FPU hardware enough to enable
+ * the exceptions, can also handle clearing the exception state in the
+ * handler. The only consequence of not clearing the exception is the
+ * rethrow of the SIGFPE on return from the signal handler and
+ * reexecution of the corresponding instruction.
*
- * The error code chosen will be one of the FPE_... macros. It will be
- * sent as the second argument to old BSD-style signal handlers and as
- * "siginfo_t->si_code" (second argument) to SA_SIGINFO signal handlers.
- *
- * XXX the FP state is not preserved across signal handlers. So signal
- * handlers cannot afford to do FP unless they preserve the state or
- * longjmp() out. Both preserving the state and longjmp()ing may be
- * destroyed by IRQ13 bugs. Clearing FP exceptions is not an acceptable
- * solution for signals other than SIGFPE.
+ * For XMM traps, the exceptions were never cleared.
*/
int
npxtrap()
@@ -623,9 +623,6 @@
fnstcw(&control);
fnstsw(&status);
}
-
- if (PCPU_GET(fpcurthread) == curthread)
- fnclex();
critical_exit();
return (fpetable[status & ((~control & 0x3f) | 0x40)]);
}
More information about the Midnightbsd-cvs
mailing list