Date: Sun, 5 Oct 1997 04:10:47 +1000 (EST) From: Douglas Thomas Crosher <dtc@scrooge.ee.swin.oz.au> To: freebsd-current@freebsd.org Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199710041810.EAA00380@scrooge.ee.swin.oz.au> In-Reply-To: <199710041627.CAA32086@godzilla.zeta.org.au> from "Bruce Evans" at Oct 5, 97 02:27:09 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710041810.EAA00380>