--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 14, 2007 at 10:36:34PM +0100, David Laight wrote:
> On Thu, Jun 14, 2007 at 02:11:12PM -0700, Bill Stouder-Studenmund wrote:
> >=20
> > What probably happened was that the tool that used to query this info u=
sed
> > the FPU in userland, and wasn't performing an FP computation across the
> > call that requested information. Thus the FPU (probably) was live, and
> > application didn't notice that the FPU registers changed values.
>=20
> Could a DIAGNOSTIC kernel be set to fault on FP use in kernel ?

No. The problem is that, strictly speaking, the FP state-saving code is FP=
=20
code in the kernel. :-) Maybe we could special-case it (maybe we already=20
special case it, I'm not sure) so state-saving would be fine.

A more reasonable option, I think, would be to optionally disable the FP=20
unit at the start of each system call. While we wouldn't catch FP use in=20
interrupt handlers, we'd cover most of the kernel.

I think it should not be part of DIAGNOSTIC though. I think it would be a=
=20
very performance intensive operation, as now every FP operation that=20
follows a system call triggers a trap. Combine libc's use of FP (printf()=
=20
I think) with its making system calls, and we have a performance hit. I=20
may be off, but I'm concerned that it'd be the kind of performance hit=20
that would make folks not use DIAGNOSTIC. A separate option, though, might=
=20
be ok.

Though truth be told, I think this is the first FP use in over a decade.=20
I'm tempted to say "ever" in the context of NetBSD, but I'm not sure. So=20
this is a very rare thing.

I think a better way to catch this is to use the compiler. Isn't there a=20
compiler flag that will cause gcc to abort when it emits fp?

Take care,

Bill

--LQksG6bCIzRHxTLp
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGcjDZWz+3JHUci9cRApvHAJ4mgrJS/zbDZBU8ze6EcuSURc557gCggtyr
zOS6b0WUr3+J0qk/4rMYlhc=
=YU29
-----END PGP SIGNATURE-----

--LQksG6bCIzRHxTLp--