*BSD News Article 27041


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!ultima!kralizec.zeta.org.au!godzilla.zeta.org.au!not-for-mail
From: bde@kralizec.zeta.org.au (Bruce Evans)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Exceptional Floating Point Exception
Date: 5 Feb 1994 06:04:09 +1100
Organization: Kralizec Dialup Unix Sydney - +61-2-837-1183, v.32bis and v.42bis
Lines: 38
Message-ID: <2iu679INN1e2@godzilla.zeta.org.au>
References: <9402011908.AA06857@puffin.usmcs.maine.edu>
NNTP-Posting-Host: godzilla.zeta.org.au

In article <9402011908.AA06857@puffin.usmcs.maine.edu>,
George P. Swanton <swanton@puffin.usmcs.maine.edu> wrote:
>Check this out!
>
>:: gdb testme
>Reading symbol data from /usr/swanton/x/testme...done.
>(gdb) r
>Starting program: /usr/swanton/x/testme 
>
>Program received signal 8, Floating point exception
>		           ^^^^^^^^^^^^^^^^^^^^^^^^
>0x1e45a in sbrk ()
>           ^^^^<----------- In sbrk!

For the i386/i387 and i486, floating point errors are supposed to be
reported on the next (non-control) FP instruction after the one that
caused an error.

Bugs in the isa design of the 386/387 interface make it impossible for
the kernel to save and restore the floating point context on i386/i387
systems without triggering any pending error.  Versions of 386BSD later
than 0.1+patchkit-0.2.4 are careful to push any error back to the user
process and not let it panic the kernel, and to handle i486's differently
so that the error gets reported when it is supposed to be.

>Now upstream from this is some floating point code, but it all runs fine 
>on Decstations running either Ultrix or OSF/1 so I'm a *little perplexed*
>about what's going on.

The other systems probably use the IEEE defaults and mask all FP
exceptions.

>BTW: this happens on both my NetBSD-0.8 and FreeBSD-1.0R systems (486dx33's)

Oops, you have a 486.  gdb has some limitations in this area, but I
thought it reported the exception address OK.
-- 
Bruce Evans  bde@kralizec.zeta.org.au