Date: Thu, 27 Aug 1998 10:27:48 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org, shocking@prth.pgs.com Cc: current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Message-ID: <199808270027.KAA04047@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> OK, I've had a look at machine/trap.h, how do I go about getting info on >> exactly was exception was caused? A brief perusal of the man pages for math Have a look at the sources :-). >As far as I know, you can't. The kernel does not pass the FP registers >as they were in the mainline program flow to your signal handler. Erm, it does precisely that. This is why FP can't be used in signal handlers (any signal handler, not just SIGFPE handlers). CPU state that isn't inline is in `struct sigcontext'. >What we need here is a system call to ask the kernel for the FP >register contents which it should have saved before entering the FP >handler. If the user required so, by a system call, sysctl variable or >kernel config option. It can't be stored in the kernel because it might be nested millions of times deep for a nested signal. >I actually didn't beleive this :-) and wrote some code to get the Just as well :-). >registers via the "hidden" third parameter to a signal handler, but in >fact the exception indication bits were cleared. The exception bits are too well hidden. They probably should be in the sigcontext, but they only in the pcb_savefpu.sv_ex_sw in the pcb where they can only conveniently be got at by debuggers. Gdb fetches them from there. My version of npx.c has an option for controlling clearing of the exception bits. I found that the current behaviour is least suprising. 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?199808270027.KAA04047>