amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor

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

 	fldz
 	fld1
 	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.

Bruce


More information about the freebsd-amd64 mailing list