Date: Sun, 30 Aug 1998 22:22:12 +0200 From: Martin Cracauer <cracauer@cons.org> To: Terry Lambert <tlambert@primenet.com>, Bruce Evans <bde@zeta.org.au> Cc: cracauer@cons.org, current@FreeBSD.ORG, luoqi@watermarkgroup.com, shocking@prth.pgs.com Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Message-ID: <19980830222212.A19455@cons.org> In-Reply-To: <199808290143.SAA29643@usr01.primenet.com>; from Terry Lambert on Sat, Aug 29, 1998 at 01:43:33AM %2B0000 References: <199808271224.WAA25445@godzilla.zeta.org.au> <199808290143.SAA29643@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199808290143.SAA29643@usr01.primenet.com>, Terry Lambert wrote:
> > >> I wrote the assembler code. Run it under gdb and look at the FP
> > >> state using `info float'. Homework: explain why this generates
> > >> only 6 SIGFPE's although it divides by 0.0 by 0.0 8 times.
> > > ^
> > >Don't you mean 7?
> >
> > Oops. I miscounted 6 and thought that it was missing 1 for both the
> > first and the last division.
>
> A general 5,000 foot view onto the "Homework" problem:
>
> FP exceptions are signalled on the FP instruction following the
> exception. That is, you have to try to use the thing again to
> generate an exception.
Or issue 'wait' or 'fwait'. What's the difference between the two,
BTW, my Intel docs treat them the same.
I use this as the last statement in a block of FP instructions prior
to code looking into flags possible set by FPE handlers. In good code,
as the last statement of a setjmp block :-)
#define forcefpe() asm("wait")
I have not been able to reproduce problems with delayed exceptions
using C. Didn't try very hard, though. Either gcc knows about the
problem and makes sure to include statements that trigger pending
exceptions before any piece of code that branches. Or it produces code
that is so noisy that your intended floating point instructions are
always followed by some triggering code :-)
> FreeBSD does lazy task switching; that it, FreeBSD does not do
> FP register saves on task switches, unless necessary, and does not
> do implict saves via TSS, since it does not use TSS for the switch
> (ie: it doesn't go through a task gate, except to get in and out
> of VM86 mode).
I don't understand how not saving the registers could lead to an FPE
delivered to the wrong process. A process could only leave with
pending exceptions if it used floating point and in that case its
registers would have been saved.
If there was any problem that a pending FPE could be delivered to a
different process, it wouldn't be affected by saving the FP registers.
I also don't how comparing the *pointers to* _npxproc and _curproc in
swtch.s and support.s leads to a decision if the FPU state
changed. Nor can I find FPU related information in struct proc or
struct mdproc/trapframe. Time for more homework...
> Non-lazy task switching would cause context switch to be much higher
> overhead (as in Linux), but would cause the exception to be raised
> in the context of the process that caused it.
And all glibc programs are floating point programs. So much for
maintaining libc and kernel in different teams.
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?19980830222212.A19455>