Date: Mon, 22 Sep 1997 00:55:38 +1000 (EST) From: Douglas Thomas Crosher <dtc@scrooge.ee.swin.oz.au> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: kern/4597: Patch to pass NPX status word in signal code. Message-ID: <199709211455.AAA06008@scrooge.ee.swin.oz.au> Resent-Message-ID: <199709211500.IAA03276@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 4597
>Category: kern
>Synopsis: Patch to pass NPX status word in signal code on SIGFPE.
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Sun Sep 21 08:00:01 PDT 1997
>Last-Modified:
>Originator: Douglas Crosher
>Organization:
Swinburne University
>Release: FreeBSD 3.0-CURRENT i386
>Environment:
N/A
>Description:
Presently it's not possible for a process to determine the cause of a
FP exception it may generate. The exceptions in the NPX status word
are cleared after an exception so the process has no way of
determining which exception occurred. The suggested change would have
the NPX status word passed in the signal code allowing the process to
determine the cause of the exception.
Being able to determine the cause of a FP exception is critical for
some numerical code, E.g. it may be used to adjust an algorithm if an
overflow occurs. Further it may indicate a bug in an algorithm,
(e.g. an unexpected division by zero), and knowing the cause of an
exception can help locate the problem.
Algorithms may also be mixing the monitoring the accrued exceptions
with some traps enabled. The clearing of all the exceptions on a
SIGFPE clears the accrued exceptions and may break such code unless
the accrued exceptions are restored by the application on a longjump;
but if the application doesn't have access to these it can't restore
them.
It is currently possible for an external debugger (gdb) to obtain the
NPX status word and report the exception. But this doesn't help an
application that needs to know the cause of an exception it produces,
or higher level languages that have their own debuggers to handle
exceptions (e.g. CMU Common Lisp).
Some operating systems will save the FP state in the signal
context. This has been discussed on the freebsd-current list some time
ago and the general consensus seemed to be that the overhead of doing
so is prohibitive. This may be the case, and if an application needs
to save the NPX state it can do so in its SIGFPE handler, however the
exceptions in the status word are currently cleared and lost.
>How-To-Repeat:
N/A
>Fix:
The patch below has the NPX status word passed in the signal
code. This allows an application to determine the cause the of
exception and to restore any accrued exceptions on a longjump.
*** npx.c.1 Thu Aug 21 23:10:27 1997
--- npx.c Sun Sep 21 21:07:27 1997
***************
*** 528,542 ****
* just before it is used).
*/
curproc->p_md.md_regs = (struct trapframe *)&frame->if_es;
- #ifdef notyet
/*
! * Encode the appropriate code for detailed information on
! * this exception.
*/
! code = XXX_ENCODE(curpcb->pcb_savefpu.sv_ex_sw);
! #else
! code = 0; /* XXX */
! #endif
trapsignal(curproc, SIGFPE, code);
} else {
/*
--- 528,538 ----
* just before it is used).
*/
curproc->p_md.md_regs = (struct trapframe *)&frame->if_es;
/*
! * Pass the NPX status word in the signal code so the
! * process can determine the cause of the exception.
*/
! code = curpcb->pcb_savefpu.sv_ex_sw;
trapsignal(curproc, SIGFPE, code);
} else {
/*
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709211455.AAA06008>