In article <Pine.NEB.4.62.0511301045200.18492@pilchuck.reedmedia.net>,
Jeremy C. Reed <reed@reedmedia.net> wrote:
>My X11 pointer was stuck to left side of screen. This led me to NetBSD PR 
>30418 (fixed by NetBSD's pkgsrc/xorg-libs/patches/patch-bl). This NetBSD 
>PR led me to xorg bug #3113
>https://bugs.freedesktop.org/show_bug.cgi?id=3113
>
>So I downloaded and compiled OpenBSD's fpsig.c regression test.
>http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/regress/sys/kern/signal/fpsig/
>
>It had inconsistent results. So I bumped up the loop as suggested to me.
>
>As I was told via the xorg bug report, this fpsig "test program computes 
>the same floating point value, using variables on the stack both in the 
>main code path and in a signal handler." Also, the xorg bug report says if 
>the signal handlers do not correctly save/restore the FPU registers, the 
>results are unpredictable and will probably not be the same (and are 
>printed). When no corruption of the FPU, the two results are the same and 
>nothing is printed (and the exit status is 0).
>
>Here is my output three times:
>
>rainier:~/tmp$ ./fpsig
>fpsig: 5700.000000 580.000000
>rainier:~/tmp$ ./fpsig
>fpsig: 5700.000000 5365.000000
>rainier:~/tmp$ ./fpsig
>fpsig: 5700.000000 5263.000000
>
>I am running NetBSD/i386 2.0.2 kernel and I have not tried this with newer 
>kernel. I looked at some source, but I am really unfamiliar with this so I 
>don't know if any changes are in netbsd-2 related to this.
>
>I was told since the the FPU context save/restore has been fixed on 
>OpenBSD/i386 no one reported this X11 pointer bug again for OpenBSD.
>
>Please see the following for some ideas:
>
>http://archives.neohapsis.com/archives/openbsd/cvs/2005-07/0599.html
>http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/genassym.cf
>http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/locore.s
>http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/machdep.c
>http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/include/frame.h
>
>Any comments about this?

3.0 and above use the sigcontext/siginfo code path by default,
and not the sigreturn/sigvec code path. The sigcontext path does
lazy fpu saving and restoring, so the fpsig program works fine.

Having said that, code should not use floating point in signal
handlers. It is non portable and wasteful because the majority of
programs don't need it.

christos