From owner-freebsd-bugs  Fri Nov 14 22:58:47 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA04293
          for bugs-outgoing; Fri, 14 Nov 1997 22:58:47 -0800 (PST)
          (envelope-from owner-freebsd-bugs)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04288
          for <bugs@freebsd.org>; Fri, 14 Nov 1997 22:58:45 -0800 (PST)
          (envelope-from sef@kithrup.com)
Received: (from sef@localhost)
	by kithrup.com (8.8.7/8.8.7) id WAA22009;
	Fri, 14 Nov 1997 22:58:44 -0800 (PST)
	(envelope-from sef)
Date: Fri, 14 Nov 1997 22:58:44 -0800 (PST)
From: Sean Eric Fagan <sef@kithrup.com>
Message-Id: <199711150658.WAA22009@kithrup.com>
To: bugs@freebsd.org
Subject: Re: Foof! bug fix? 
In-Reply-To: <199711150535.VAA15414.kithrup.freebsd.bugs@implode.root.com>
References: Your message of "Fri, 14 Nov 1997 17:57:37 MST."
             <3.0.5.32.19971114175737.00928b90@mail.lariat.org> 
Organization: Kithrup Enterprises, Ltd.
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In article <199711150535.VAA15414.kithrup.freebsd.bugs@implode.root.com> you write:
>   We're evaluating what looks to be a far superior (and simpler!) fix that
>was proposed by Jonathan Lemon (a FreeBSD contributor). Again, we want the
>"right" fix, not just the "right now" fix. I've appended Jonathan's proposal
>to the end of the message in case you need something "right now". :-)

It's important to realize that this "far superior (and simpiler!)" "fix"
breaks existing practice and code.

Specifically, it causes all illegal instructions to generate a SIGBUS,
instead of the current SIGILL.  Note that this means a program would behave
differently on two different machines, running identical versions of the
operating system -- unless, of course, illegal instructions are suddenly
defined to always generate SIGBUS.

This can be changed by having trap() identify faults which are due to
illegal instructions, and which are other general protection faults.  I
wasn't able to see an easy way to do that, and I've expressed my concern to
Jonathan.

I think it unlikely that Intel did not think of this attempt; assuming they
did, there is a very good reason that they did not give this as their
official workaround.