Re: x87 status word size
Re: x87 status word size
- Subject: Re: x87 status word size
- From: Jonas Maebe <email@hidden>
- Date: Tue, 16 Jun 2009 00:34:24 +0200
On 15 Jun 2009, at 23:58, Terry Lambert wrote:
On Jun 15, 2009, at 11:11 AM, Jonas Maebe
<email@hidden> wrote:
Why is the x87 tag word field (__fpu_ftw) in
_STRUCT_X86_FLOAT_STATE32 in osfmk/mach/i386/_structs.h only 8
bits? The hardware tag word is 16 bit. I guess it "overflows" into
the next "__fpu_rsrv1" field when saving/restoring the fpu state,
so in practice it probably doesn't really matter as long as you
don't directly access it (but I would like to do so, to reset the
fpu state within a signal handler).
Generally, it's to make it a pain to do what you are trying to do so
that you will reconsider and not do it.
Right, I should have known that this would be the reason :)
x87 exceptions are not definite exceptions, so the state that you
will be mucking with after a SIGFPE is thrown is the state some time
past the point of the exception that caused it to be raised.
I know, but that's not a problem: I'm doing a complete reset of the
x87 state inside the signal handler and then jump to my language run
time's exception handler (by setting the eip in the thread context to
that routine's address). I'm not doing a siglongjmp to my handler
because of earlier bad experiences on ppc (see http://lists.apple.com/archives/darwin-dev/2008/Nov/msg00086.html)
I haven't gotten around yet to converting our unix signal handlers
into mach signal handlers...
You should really be using fegetexceptflag/fetestexcept/
feclearexcept et. al
Are those perhaps new in Snow Leopard? "apropos" on Leopard doesn't
turn up anything for those functions. And are these usable inside a
SIGFPE exception handler to reset the "fpu stack pointer" of the
current context?
The problem I have is that
a) a value is loaded on the fpu stack
b) an invalid operation is performed on that value, resulting in a
SIGFPE
c) the signal handler clears all "exception happened" flags in the fpscr
d) the signal handler returns to the language run time signal handler,
which converts the signal into a language exception
As a result, the value loaded in step a) remains on the fpu stack, so
after 7 exceptions the fpu stack is permanently full. Maybe the best
solution is simply to perform an fninit in the language run time
signal handler of step d) for darwin/x86, but that would introduce an
OS/cpu-dependency in code that is currently completely OS and cpu
neutral.
to make your code processor neutral, rather that bit-banging on the
current thread state (the only exception to this would be if you
were writing a debugger), since we won't promise to not change the
context layout or contents at some future date.
I'm not writing a debugger. This code is for the run time library of
our compiler (this obviously only makes it worse, because it means
that there are already quite a few apps out there that may break when
such a change occurs).
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden