From owner-freebsd-current  Wed Aug 26 17:29:03 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA25805
          for freebsd-current-outgoing; Wed, 26 Aug 1998 17:29:03 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA25799
          for <current@FreeBSD.ORG>; Wed, 26 Aug 1998 17:28:59 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id KAA04047;
	Thu, 27 Aug 1998 10:27:48 +1000
Date: Thu, 27 Aug 1998 10:27:48 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199808270027.KAA04047@godzilla.zeta.org.au>
To: bde@zeta.org.au, cracauer@cons.org, shocking@prth.pgs.com
Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>> 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