Date: Mon, 31 Aug 1998 21:27:36 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Message-ID: <199808311127.VAA25654@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Er, no. The exception status word is a bitmap. Code to map it to a
>> machine_dependent exception code should look something like:
> ^^
> independent?
-independent :-)
The 6 standard IEEE exceptions can be mapped to the same binary code for
all machines. Probably not very useful, but easy to do. i386's also have
an FP stack overflow exception. This gets reported as a invalid operand
exception and a stack fault exception (bit 0x40 for the latter). This
should probably be reported as a stack fault exception only.
>> code = translation_table[ffs(status_word & control_word & 0x3F)];
>
>But the values of the symbols the application tests against
>("FP_X_...") are chosen so that no translation is needed.
Sorry, I thought that you didn't change the codes that much.
>Your translation table would look like this:
>tab[0x01] = 0x01
>tab[0x02] = 0x02
>tab[0x04] = 0x04
>...
>tab[0x20] = 0x20
I used ffs() so I don't have to worry about more than one bit being set.
It's probably better use use a table of size 0x80 to cover the stack
exception bit and not depend on ffs() for priority decoding. E.g.,
0x41 (invalid operand + stack fault) should be mapped to the code for
a stack fault unless we do lots more work to untangle the bits - the
stack fault bit may be set without there being stack overflow in the
previous FPU instruction because it is sticky.
>Is it really canon that we should bloat the kernel with tables like
>this that are needed only when someone make undesired changes to a
>machine/ header file?
No, but ...
>...
>It is my intent to delete all bits but the one that caused this
>particular exception, to tell the application why it entered the
>exception handler (and nothing else).
... you need a table to tell which bits to delete.
>I expect this to leave one bit only. Is it really the case that more
>than one bit for unmasked exceptions can be set before the FPE is
>triggered?
All bits may be set if the application fiddles with the control word,
e.g.:
1. mask (traps for) all exceptions (fninit)
2. cause all exceptions (including a stack exception)
3. unmask one exception (fldcw)
4. attempt to execute a non-control FP instruction
This will trap in step 4. All exception bits will be set, and the FPU's
cs:eip will point to the last instruction that caused an exception in
step 2.
>If the application wants to know about more bits set (from masked
>exceptions), it has to fetch the status word itself. There is no need
>for kernel code to support that.
Yes there is, since the kernel part of the trap handler clears all
exceptions (it has to, so that the application can continue after
returning from the SIGFPE handler. OTOH, the application shouldn't
return from the SIGFPE handler).
>> >+ #include <machine/floatingpoint.h>
>> >+
>>
>> This header is application-only.
>
>I need it for the __fnstcw macro. What to do instead, insert the asm()
>directives directly? That would be duplication of code. Move the
>__fnstcw() macro to a header that is for kernel and applications?
npx.c has its own fnstcw() macro. It also has a pseudocode macro named
XXX_ENCODE() which needs to be completed to fix this problem.
>> The FPU can't be used here if there was a context switch between the
>> FPU trap and here.
>
>So I have to treat it like curpcb->pcb_savefpu.sv_ex_sw, that means I
>store it into a new field curpcb->pcb_savefpu.sv_ex_cw in
>npx.c:npxintr() ?
Just translate the code there. You do need to store the control word
somewhere.
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?199808311127.VAA25654>