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