Return to BSD News archive
Newsgroups: comp.os.386bsd.apps Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde From: bde@runx.oz.au (Bruce Evans) Subject: Re: Ghostscript 2.5.2 dies with floating point exceptions Message-ID: <1993Mar25.183152.6512@runx.oz.au> Keywords: Ghostscript floating point exception Organization: RUNX Un*x Timeshare. Sydney, Australia. References: <cproto.733031902@marsh> <1orqvu$fpv@hal.gnu.ai.mit.edu> Date: Thu, 25 Mar 93 18:31:52 GMT Lines: 46 In article <1orqvu$fpv@hal.gnu.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes: > >In article <cproto.733031902@marsh> cproto@cs.curtin.edu.au (Computer >Protocol) writes: >... >> 2. Has anybody fixed the delayed delivery of SIGFPEs? I have, following a hint by Paul Kranenburg. The results of signotify() were being ignored. signotify(p) is just aston() which is just astpending++. doreti() needs to test and clear astpending instead of testing want_resched. This also fixes the delayed delivery of keyboard signals (the delivery of SIGFPE was always delayed, and the delivery of keyboard signals was delayed for keyboard signals that arrive while kernel code is running). Correct SIGFPE delivery requires a little more work to get doreti() called after traps and syscalls. >The only way to force a FPE to be trapped immediately after the insn >which caused it is to put FWAITs everywhere. This slows down the code. >It might be nice if GCC used FWAITs when compiling without -O. This fixes a different problem. (x87) instructions that cause a floating point error should never trap immediately. The trap should occur on the next "no-wait" FP instruction. In practice there is almost always a "next" FP instruction inside each C expression so that FWAITs are rarely needed. Consider x = y + z where y + z overflows. The trap should not occur when y + z is calculated. It should occur when the result is assigned to x and the assignment is usually done immediately (without -O). One place where an fwait is definitely needed is fixdfsi.s. It finishes with a double -> int FP instruction. If the conversion overflows, the FP error will be reported in an unrelated context. However, fixdfsi.s is broken anyway (it does incorrect rounding) and fixing it naturally introduces a "next" FP instruction and gets the error reported. Another problem is that context switching in effect inserts a bogus fwait in the instruction stream at each switch, so the timing of the delivery of FP traps is randomly changed (by time slicing) and non-randomly changed (by debugging). This doesn't matter for normal code, except that the extra context switches at for debugging tend to activate some other x87/kernel bugs. It matters a lot for debugging at the level of individual x87/x87 instructions. The kernel problems are mostly fixed in my npx-0.4.tar.Z package. Unfortunately the 387 support is compeltely broken. It works for 486's. -- Bruce Evans bde@runx.oz.au