From owner-freebsd-current  Sat Oct  4 11:07:39 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA28235
          for current-outgoing; Sat, 4 Oct 1997 11:07:39 -0700 (PDT)
Received: from scrooge.ee.swin.oz.au (scrooge.ee.swin.oz.au [136.186.4.20])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA28229
          for <freebsd-current@freebsd.org>; Sat, 4 Oct 1997 11:07:33 -0700 (PDT)
Received: (from dtc@localhost) by scrooge.ee.swin.oz.au (8.6.9/8.6.9) id EAA00380 for freebsd-current@freebsd.org; Sun, 5 Oct 1997 04:10:48 +1000
From: Douglas Thomas Crosher  <dtc@scrooge.ee.swin.oz.au>
Message-Id: <199710041810.EAA00380@scrooge.ee.swin.oz.au>
Subject: Re: xlock: caught signal 8 while running galaxy mode.
To: freebsd-current@freebsd.org
Date: Sun, 5 Oct 1997 04:10:47 +1000 (EST)
In-Reply-To: <199710041627.CAA32086@godzilla.zeta.org.au> from "Bruce Evans" at Oct 5, 97 02:27:09 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


> >I want to be able to catch an exception, if I want, and determine what
> >the cause of the problem was, and, possibly work around it.  I want my
> >exception handler to know exactly what the exception was.
> 
> Here is the (unfinished) code for it (in npx.c):
...
> The signal code for a SIGFPE can also be FPE_INTDIV_TRAP (integer divide
> fault), FPE_INTOVF_TRAP (integer overflow fault), FPE_SUBRNG_TRAP (bounds
> check fault) or FPE_FPU_NP_TRAP (no FPU h/w and no FPU emulator).  This
> already works.  See trap.c and trap.h.

Simply returning a few general codes is not enough. Apart from
detecting exceptional values, applications many also depend on a
combinations of:

1. Enabling and detecting specific exceptions. E.g. An overflow,
underflow, loss of precision etc. Not possible in FreeBSD.

2. Monitoring the accrued exceptions. Not reliable in FreeBSD as a
SIGFPE will clear these and gives the application no chance of
restoring them when doing the equivalent of a long jump.

If freebsd isn't going to save the NPX state in the sigcontext then
perhaps it could pass the status word back to the application - see
PR4597. This would at least give the application a chance of doing the
right thing.

Regards
Douglas Crosher