Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Sep 1998 15:13:07 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, cracauer@cons.org, current@FreeBSD.ORG
Subject:   Re: Floating Point Exceptions, signal handlers & subsequent ops
Message-ID:  <199809070513.PAA26505@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> >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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809070513.PAA26505>