amd64/169927: siginfo, si_code for fpe errors when error occurs
using the SSE math processor
brde at optusnet.com.au
Tue Jul 17 16:04:19 UTC 2012
On Wed, 18 Jul 2012, Bruce Evans wrote:
> On Wed, 18 Jul 2012, Bruce Evans wrote:
>> So I still want a single kernel exception handle that merges the statuses.
> Merge the independent statuses modified by their independent controls:
> return (fpetable[(fpsw & ((~fpcw & 0x3f) | 0x40)) |
> ((mxcsr & (mxcsr >> 16)) & 0x3f)]);
> Use the same trap handler that reads all these statuses and controls.
Changed my mind again. Need sleep. Merging the traps breaks the rule
that i387 traps occur on the first non-control instruction after the
one that causes the exception. There may be mixed code like this:
fdiv %st,%st(1) # i387 exception now; i387 trap pending
load $0 into %xmm0
load $1 into %xmm1
divsd %xmm0,%xmm1 # SSE exception now; SSE trap now
Debuggers can see both exception states including the i387 trap pending,
provided the i387 trap is not bogusly cleared, either by never clearing
it in the kernel trap handler or by using a separate trap handler that
doesn't clear it for T_XMMFLT. They can even figure out that an SSE
trap occurred, because the i387 trap is still pending.
fnop # i387 trap on first non-control FP instr...
Apart from doing the bogus fnclex for T_XMMFLT and the delayed effect of
i387 status bits, merging or not merging the statuses makes little
difference, since if a status bit is set and is not masked according
to its control word, then it will generate a trap soon if it didn't
genearate the current one.
More information about the freebsd-amd64