site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 15 Jun 2009, at 23:58, Terry Lambert wrote: Right, I should have known that this would be the reason :) Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jun 15, 2009, at 11:11 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> 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. 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). This email sent to site_archiver@lists.apple.com