Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jul 2012 02:03:58 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        freebsd-amd64@FreeBSD.org
Subject:   Re: amd64/169927: siginfo, si_code for fpe errors when error occurs using the SSE math processor
Message-ID:  <20120718014222.V7761@besplex.bde.org>
In-Reply-To: <20120718011942.D7642@besplex.bde.org>
References:  <201207171350.q6HDoAJS033797@freefall.freebsd.org> <20120717235622.C7417@besplex.bde.org> <20120718011942.D7642@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120718014222.V7761>