Date: Mon, 7 Sep 1998 08:19:50 +0200 From: Martin Cracauer <cracauer@cons.org> To: Bruce Evans <bde@zeta.org.au>, cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Message-ID: <19980907081950.A24058@cons.org> In-Reply-To: <199809070513.PAA26505@godzilla.zeta.org.au>; from Bruce Evans on Mon, Sep 07, 1998 at 03:13:07PM %2B1000 References: <199809070513.PAA26505@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199809070513.PAA26505@godzilla.zeta.org.au>, Bruce Evans wrote:
> >> >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.
The kernel has no support, but their struct sigcontext contains the
saved control and status words (I tried), so people can compute them
themself. That's probably the reason it isn't a priority for them.
The Linux folks also have a serious problem that the kernel and glibc
maintainers don't work together on floating point. See the "Why every
glibc-(2) program is a floating point program" on linux-kernel.
[...]
> I'd like to have FPU exceptions masked by default in 3.0.
Sounds good, I reviewed some of the issues you sent me over the years,
is there something I could help with? I'm already building the 256
value table for the trap code.
You're probably not going to mess with the gcc problems with
compile-time evaluation, are you :-/ ?
I understand why you try to keep throwing FPEs for stack
overflow. Masking everything but invalid operations doesn't help much,
since compares with NaN or other invalid arithmetic will quickly
occour in programs that don't care, cause an invalid exception and
raise complaints about dying screensavers :-)
Maybe we can unmask FP_X_INV by default, but as long as the user sets
no handler for SIGFPE, we handle it inside the kernel, throwing FPE if
its a stack fault and if not insert the value as computed with masked
exception as the result of the operation? Gross hack...
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
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?19980907081950.A24058>