Reply to topic  [ 1 post ] 
SIGFPE on MacOS X 10.5 
Author Message
Yorick Master

Joined: Mon Nov 22, 2004 9:43 am
Posts: 354
Location: Livermore, CA, USA
Post SIGFPE on MacOS X 10.5
Revision 1.6 of play/unix/fpuset.c fixes the bug described in the following email:

Steve and Mike,

I just checked in a new fpuset.c to CVS at, which works on MacOS X 10.2 through 10.5, but which will now fail on MacOS X 10.1, unless you set FPU_MACOSX_10_1 by hand in Make.cfg.

The old MacOS X PPC binary distribution at works perfectly (as far as I can tell) under MacOS X 10.5. The failure to compile (it got FPU_IGNORE during configure if you checked) under 10.5 was caused by a change in the system header files, so that the ppc_thread_state struct is no longer defined. When the __DARWIN_UNIX03 macro is defined, which it is by default (I have no idea what that means), an identical struct is defined, but with a different name and with different names for its members (the struct just holds copies of all the registers like an exchange package). Since only the names have changed, the old 10.4 binary still works fine.

The only reason thread code is there at all is to set the MSR bit that enables the FPE enable bits in the SCR (that's right, enabling enable bits is a PPC feature). A thread cannot set its own MSR bits, so you need to start a new thread, suspend the original, have the new thread jigger the MSR in the state of the original thread, resume the original thread, then rejoin the new thread. Yuck. Since 10.2, MacOS X has set the MSR bits correctly by default (like all versions of AIX), so all this silliness is unnecessary.

My fix therefore, was to eliminate the code that creates threads and modifies the MSR bits. Obviously this is much cleaner than the original, taking advantage of the bug fix between 10.1 and 10.2 that fixed the initial MSR state. I rejected a fix which retains the thread code, conditionally switching to the new struct member names, partly because I can't find any documentation to understand whether I am conditionalizing it correctly (I have no idea what __DARWIN_UNIX03 in the system header files means, why it is set or not, and whether I am intended to use it in my code). I left the old code in place, but you have to define FPU_MACOSX_10_1 in Make.cfg by hand to get it; the configure script doesn't try.

The one possibly negative side effect is that code built under 10.2 or higher has no chance of catching SIGFPE on a 10.1 system. As I said, I've decided that's not a bug.


Sat Nov 10, 2007 12:17 pm
Display posts from previous:  Sort by  
Reply to topic   [ 1 post ] 

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.