From owner-freebsd-current Sun Sep 6 22:13:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA16675 for freebsd-current-outgoing; Sun, 6 Sep 1998 22:13:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA16670 for ; Sun, 6 Sep 1998 22:13:20 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id PAA26505; Mon, 7 Sep 1998 15:13:07 +1000 Date: Mon, 7 Sep 1998 15:13:07 +1000 From: Bruce Evans Message-Id: <199809070513.PAA26505@godzilla.zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >OK, I had another look and Linux and Solaris both have >> >#define FPE_INTDIV 1 /* integer divide by zero */ >> >#define FPE_INTOVF 2 /* integer overflow */ >> >#define FPE_FLTDIV 3 /* floating point divide by zero */ >> >#define FPE_FLTOVF 4 /* floating point overflow */ >> >#define FPE_FLTUND 5 /* floating point underflow */ >> >#define FPE_FLTRES 6 /* floating point inexact result */ >> >#define FPE_FLTINV 7 /* invalid floating point operation */ >> >#define FPE_FLTSUB 8 /* subscript out of range */ >I didn't find hard documentation on these values, but everybody (see >below) supports them :-) >... >linux-kernel-2.1.x has the FPE_...... names from above, newer glibc >has them as well, but these FPE_......_{TRAP,FAULT} seem to be >hurd-only. The FPE_...... values seem more attractive to me. Linux-2.1.115 doesn't seem to actually support them except on m68k's. It only defines for other arches. >Regarding the decision which bits to ignore when multiple unmasked >bits are set, I found something in an Intel document. Wording is >mine. >... >I think using the same scheme as the FPU makes sense. If the user >messes with the control word while using FPU instructions while having >an exception handler for SIGFPE set, we could as well define the >behaviour as undefined. But we need the table you suggested in any >case, since we need to look at multiple bits for stack over/underflow >at least, so we can implement something halfway reasonable. I agree. >I could also imagine extending struct sigcontext with fields for >control and status word so that the user can get the unmodified status >if the one-bit trap code isn't sufficient (either because multiple >bits may have been set or if the FPE_...... values aren't precise >enough, for example if the user needs to tell under- from overflow). This can wait until we implement SA_SIGINFO (post-3.0). I'd like to have FPU exceptions masked by default in 3.0. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message