September 2009 - Darwin-dev

Problem using .zerofill / -segaddr to create very large segments
by Jay Reynolds Freeman 21 Sep '09

21 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I have a problem using the -segaddr linker flag in an Xcode build. Here are a few more details: .zerofill __WSS, __Wss000, _WraithSpace, 0x40000000 .zerofill __WSS, __Wss001, _zz001, 0x40000000 .zerofill __WSS, __Wss002, _zz002, 0x40000000 ... .zerofill __WSS, __Wss156, _zz156, 0x40000000 .zerofill __WSS, __Wss157, _zz157, 0x40000000 .zerofill __WSS, __Wss158, _zz158, 0x40000000 .zerofill __WSS, __Wss159, _zz159, 0x40000000 .zerofill __WSS, __Wss160, _zz160, 0x40000000 Thank you very much. -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman(a)mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I have a problem which might be Xcode, Darwin, or even Cocoa; I ran this posting past the Xcode list a few days ago with no insightful developments, so my next thought was to ask here if anyone had a clue... I am building a 64-bit Macintosh application using Xcode 3.2 on MacOS 10.6.1, on an early-2008 model Mac Pro. The build targets architecture x86_64, uses the LLVM GCC 4.2 compiler, has a Mac OS X Deployment Target of Mac OS X 10.6, and if you would like to know any other build settings, let me hear from you. My problem concerns keeping a block of memory out of the clutches of the storage allocator (malloc, new, et cetera), so that I can use it for mmap. I do have a solution to do that, which DOES work, which is: 1) Include in my build a ".s" file that contains appropriate .zerofill directives to define a segment large enough for my purposes. 2) Tell the linker where to put that segment by putting, e.g, "- segaddr __WSS 0x10000000000" in the "Other Linker Flags" entry of the build rules pane of the Xcode information panel for the target for my application. This all works fine, and has been working for months, and I am not having any problem with mmap (knock on wood). My problem is that I need a *very* large segment -- at the moment I am using 160 Gigabytes (segment length #x2800000000 bytes, and remember, this is 64-bit code). I need to make the segment even larger for a forthcoming upgrade of the application, and I appear to be running up against some kind of limitation on the total size of segments created in this manner. It has been decades since I have written Intel x86 assembler in any form, and I have always regarded the linker as rather a black box and not tried to use unusual flags. So I hope I am merely making some embarrassingly simple mistake, but I have checked the man pages and the web, and I cannot find any useful clues. (By the way, since someone asked on the Xcode list, I will mention that I need a large shared segment for use in a parallel -- separate Unix processes -- Lisp system with shared Lisp main memory. I would be happy to talk about it off-list if anyone is interested.) I haven't been able to make the .zerofill directive understand 64-bit numbers -- #x1234567890LL and similar suffixes result in errors or incorrect linkages. So my ".s" file actually contains a lot of adjacent .zerofills, as follows: That is a total of 160 one-Gigabyte blocks, all in segment __WSS. That works fine, and has been working for months. The problem comes if I add even one more .zerofill block at the end of that file, creating a segment of 161 GByte instead of 160 GByte: In that case, the Xcode build completes (I do a clean and a complete fresh build) with no errors reported, BUT I get run-time errors when I launch the application, while the framework is still getting going, long before the actual mmap has taken place. Here is the first of many run-time errors, as reported in the Console Messages log. The error kind of makes sense, in that my application does indeed have the indicated class and should indeed be trying to load it at launch time (but why increasing the segment size has made it impossible to load the class is beyond me): 9/19/09 1:06:32 PM Wraith Scheme[35427] Unknown class JRF2NSTextView in Interface Builder file at path /Users/JayFreeman/Developer/Scheme/ WraithScheme.64/WraithCocoa/build/Release/Wraith Scheme.app/Contents/ Resources/English.lproj/MainMenu.nib. If I remove the extra .zerofill, re-clean and rebuild, all is well again. I have tried changing the address for __WSS that I provide via the - segaddr flag. I have also tried adding the additional reserved memory in a different segment (eg, .zerofill __MMS, __Mms000 _mm000, 0x40000000) with an additional -segaddr flag in "Other Linker Flags". Neither works. It looks like the system doesn't like to have the total size of reserved segments larger than about 160 GByte. (As you may have guessed, I learned about this limit by tripping over it; it is no accident that my present ".s" file defines precisely 160 GByte of reserved segment.) I am leaning toward thinking this is an Xcode problem, but I would be eager to know whether anyone can find any obvious error in my use of .zerofill and -segaddr, or whether anyone can think of anything in the Darwin body of code that might cause this phenomenon. Pointers to more documentation would also be very useful; I have spent a while searching, but I am such a stranger to x86 assembler and to the linker that I may very well be using the wrong search keywords, and my knowledge of Darwin _per_se_ is rather, er, unevolved ... This email sent to site_archiver(a)lists.apple.com

1 0

gdb and procmod on darwin9.8/darwin10
by Jack Howarth 21 Sep '09

21 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.18 (2008-05-17) The gdb developers are rapidly approaching the release of gdb 7.0 (which will be required to debug optimized code generated by gcc 4.5 due changes related to the var tracking association merge and other code). They currently have patches proposed that allows gdb 7.0 to debug code in darwin9.6. However there was some change made in darwin9.8 and darwin10 which no longer allows the previous approach of making gdb belong to the procmod group... sudo chgrp procmod gdb sudo chmod g+s gdb Under darwin9.6 and darwin10 (but not darwin9.5), this results in the error... (gdb) break 4 Breakpoint 1 at 0x10000154c: file himenoBMTxpa.c, line 4. (gdb) r Starting program: /Users/howarth/a.out Unable to find Mach task port for process-id 154: (os/kern) failure (0x5). (please check gdb is setgid procmod) (gdb) Can someone at Apple provide the gdb developers with some advice on what is the new approach recommnded for gdb to have proper permissions and group ownership to function under darwin9.5.8 and darwin10? The messages discussing this issue are archived at... http://sourceware.org/ml/gdb/2009-09/msg00239.html http://sourceware.org/ml/gdb/2009-09/msg00240.html http://sourceware.org/ml/gdb/2009-09/msg00241.html http://sourceware.org/ml/gdb/2009-09/msg00242.html http://sourceware.org/ml/gdb/2009-09/msg00243.html http://sourceware.org/ml/gdb/2009-09/msg00245.html http://sourceware.org/ml/gdb/2009-09/msg00246.html http://sourceware.org/ml/gdb/2009-09/msg00247.html http://sourceware.org/ml/gdb/2009-09/msg00248.html http://sourceware.org/ml/gdb/2009-09/msg00249.html http://sourceware.org/ml/gdb/2009-09/msg00250.html http://sourceware.org/ml/gdb/2009-09/msg00252.html Thanks for any authoritative answer on the correct approach to solving this problem. Jack _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

anyone prepared to estimate the probability of dwarfutils becoming Open Source?
by IainS 20 Sep '09

20 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com as per the subject. is a request for Open-sourcing an appropriate Radar? Iain _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

A Question on CoreFoundation Deployment Targets
by Brent Fulgham 16 Sep '09

16 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=umBmS3kysfdqVT1rnceNGIY/+HJk/OgksImCswqBSDM=; b=M+xn+6UiG8yLRwzWn/gScRYhCuAptHICHYZ5y0yorDZw17COQeBTaZm1rdBjKIMxAX 7Ifsq/2onwkd6tIsA5moAsLhn6kcqE6X28Gee4MxTv8YcXwoFhjZlqZ1C+d6ku7iEgN9 0LjdmJdZY+/5uBuOrnTtmqs0I8RPOSdqgYQlY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fbt7oPjjZsjR+glvaP7AluPkUZS2HEuepAosc1c/p4r5lhfYWMjX9apgzMfop6QcsJ +bu5wjyCaxVHNdiw3yh6K7SJn41/7acrIQT5Cm6mmJRrU+LXQeDD3pPag4u7l3xk+3HV Lxm5tqbwhty+v1kAqOtc2YNtcembNdl4atcxE= The new CF-550 sources contain a few conditional implementations based on the value of the preprocessor macros. In addition to the expected DEPLOYMENT_TARGET_WINDOWS, I now find the new "DEPLOYMENT_TARGET_WINDOWS_SYNC" and "DEPLOYMENT_TARGET_WINDOWS_SAFARI". It seems that DTW contains things common to DTW_SYNC and DTW_SAFARI, but I'm not sure which of these two is the 'correct' version to be using for non-Apple projects. For now I'm assuming the DTW_SAFARI is the correct choice since it seems to most similar to what used to be the plain vanilla DTW macro. Can anyone confirm that this is reasonable? -Brent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Floating-point exception handling
by David N. Williams 16 Sep '09

16 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: University of Michigan User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Terry Lambert wrote: > Your handler there functions by casting the void * argument to a > ucontext_t pointer and then operating on the floating point state and > the saved state register contents in the context structure which blows > those values in the saved state on the stack. Then when the signal > trampoline returns to kernel space via __sigreturn at the end of the > signal function, it blows this back into the active thread state > structure for the pre-trampoline thread state for the active thread from > which the exception was raised, hopefully having fixed up the exception. > > It is an icredibly naieve implementation, using unsupported data > structures (meaning we are not going to promise to not change them on > you from software update to software update), since we can safely update > our exception management code in lockstep between our runtime and our > kernels, and you can't, because you are unable to make simultaneous > releases with no lag. We don't make those changes capraciously, but we > do ocassionally make them. > > The implementation is naieve because there are actually 5 possible > ucontext_t layouts on the PPC ISA, and you happened to pick the G4, > meaning 32 bit PPC, which is relatively the most stable possible one, > and one for which there was only a single layout. > > For Intel ISA, there are 5 possible layouts, and that's not including > all the ones that were shipped as part of technology previews in WWDC > builds (I will say that there have been at least 7). > > For you to build an exception handler in a signal handler that did > exactly the same thing on Intel, you would need to distinguish at > runtime which layout was being used, and then patch up the right > locations. For the structures to have the right offsets and members, you > would likewise have to use a particular compilation environment (which I > will not note here, since it could be misinterpreted as documenting it). > > Finally, since some of the registers spilled could be used to thwart > system security if their contents are modified, a shadow is kept in the > kernel, and they are reset back to their previous values, ignoring > whatever you do to them with signal stack hacking in user space. Thanks for the explanation. The handler I actually wrote doesn't do anything with ucontext_t -- it just reports which floating-point exception occurred based on the SIGFPE code returned in the siginfo_t structure, and aborts into the Forth interpreter. I quoted the Apple legacy example partly in the hope that I might have missed a more up to date version, which might allow something more useful to be done. Anything seems possible when you're ignorant. :-( > Finally, if you are using x87, Intel floating point exceptions are > inexact (if you are on a 754 working group, you will already be > painfully aware of this fact). Because of this, delayed delivery of > exceptions via signal handlers (the signal trampoline generally fires as > a result of an AST set on a Mach kernel thread state structure as a > result of a unix system call return after running up to the user > space/kernel boundary, so it could be delayed considerably, just on > Tru64 UNIX) can decouple the exception state at the time of the > exception from the exception state you are trying to hack saved > registers on the signal stack in order to fix up. This reinforces what I was warned about by a knowledgeable member of the group. > So I will tell you what I have told others who are trying to fix up > exceptions in their own runtimes: handle them as Mach exceptions, rather > than using signal handlers. Okay, I'll leave that to a more ambitious implementor. As a practical matter, reporting which exception and stopping seems good enough for nondefault floating-point handling. > Obviously, I can't keep you from puzzling out the bits you would need to > hack to deal with runtime recognition of which of the several contexts > we use in the signal stack are used in yours, since we publish both our > xnu sources and our gdb changes, but if you do, you're basically on your > own, and shouldn't be surprised if at some software update in the future > your code stops working, for the reasons listed above. I have no desire to circumvent supported interfaces. Thanks for taking the time to provide some perspective! -- David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Floating-point exception handling
by Terry Lambert 16 Sep '09

16 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry I am part of an ad hoc group working on a Forth language standard for IEEE 754 (2008) floating point, and I'm trying to do an example implementation of alternate handling for floating- point exceptions with gcc/Darwin, for one of the C-based Forths. It's my first attempt at writing a signal handler, but I was able to get it working pretty well on my PowerPC G4, with the sample code quoted below as a guide. The sample code is apparently an update of Listing 7-1 in the 2004 version of "PowerPC Numerics". My question is, what's the analogous magic for OS X intel? AFAIU, there are two issues, enabling nondefault exception handling, and dealing with state in the handler. The sample code deals with state only by restoring it when the handler returns. I might be able to figure out the intel analog for the ppc assembly language functions used for enabling, fegetenvd() and fesetenvd() quoted below; but I wouldn't mind a little hand holding on that. I didn't find any documentation on what's going on with state restoration in myHandler(), and so don't have a clue how to change that for intel. Thanks for any suggestions. -- David ----------- /* The following sample code is slightly modified to get it to compile with gcc version 4.0.1 (Apple Inc. build 5493) under OS X 10.5.8 and ppc. The original is here: http://lists.apple.com/archives/unix-porting/2003/May/msg00026.html See also Listing 7-1 in "PowerPC Numerics", 2004: http://developer.apple.com/documentation/Performance/Conceptual/Mac_OSX_Num… -- David N. Williams, 15-Sep-09 */ #include <stdio.h> #include <math.h> #include <fenv.h> #include <signal.h> #include <ucontext.h> #include <mach/thread_status.h> #include <stdlib.h> // for exit() #define fegetenvd(x) asm volatile("mffs %0" : "=f" (x)); #define fesetenvd(x) asm volatile("mtfsf 255,%0" : : "f" (x)); enum { FE_ENABLE_INEXACT = 0x00000008, FE_ENABLE_DIVBYZERO = 0x00000010, FE_ENABLE_UNDERFLOW = 0x00000020, FE_ENABLE_OVERFLOW = 0x00000040, FE_ENABLE_INVALID = 0x00000080, FE_ENABLE_ALL_EXCEPT = 0x000000F8 }; typedef union { struct { unsigned long hi; unsigned long lo; } i; double d; } hexdouble; // void myHandler(int sig, siginfo_t *sip, struct ucontext *scp) void myHandler(int sig, siginfo_t *sip, ucontext_t *scp) { hexdouble t; // superfluous in this example ppc_float_state_t *fs; ppc_thread_state_t *ss; // fs = &scp->uc_mcontext->fs; fs = &scp->uc_mcontext->__fs; // ss = &scp->uc_mcontext->ss; ss = &scp->uc_mcontext->__ss; fprintf(stdout, "SIGFPE at 0x%x invokes myHandler, fpscr = %08X\n", // sip->si_addr, fs->fpscr); sip->si_addr, fs->__fpscr); // fs->fpscr &= FE_ENABLE_ALL_EXCEPT; fs->__fpscr &= FE_ENABLE_ALL_EXCEPT; // Re-arms interrupts when this state is restored // ss->srr0 += 4; // Advances the PC when this state is restored ss->__srr0 += 4; // Advances the PC when this state is restored // fprintf(stdout, "fpscr = %08X\n", fs->fpscr); fprintf(stdout, "fpscr = %08X\n", fs->__fpscr); fflush(stdout); } int main( int argc, char **argv) { float s; hexdouble t; fegetenvd(t.d); t.i.lo |= FE_ENABLE_ALL_EXCEPT; // Enable hardware trapping for all exceptions fesetenvd(t.d); if (sigaction(SIGFPE, &act, (struct sigaction *)0) != 0) { // Set handler perror("Yikes"); exit(-1); } fegetenvd(t.d); s = HUGE_VALF * HUGE_VALF; // Overflow folded out by compiler s = s / (1.0 + s); // Inf/Inf raises invalid operation fegetenvd(t.d); fprintf(stdout, "In main(1), s computed as: %e , fpscr = %08X\n", s, t.i.lo); // keep the compiler honest ... s = HUGE_VALF * HUGE_VALF; // Overflow folded out by compiler s = s / (2.0 + s); // Inf/Inf raises invalid operation fegetenvd(t.d); fprintf(stdout, "In main(2), s computed as: %e , fpscr = %08X\n", s, t.i.lo); // keep the compiler honest ... return 0; } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Your handler there functions by casting the void * argument to a ucontext_t pointer and then operating on the floating point state and the saved state register contents in the context structure which blows those values in the saved state on the stack. Then when the signal trampoline returns to kernel space via __sigreturn at the end of the signal function, it blows this back into the active thread state structure for the pre-trampoline thread state for the active thread from which the exception was raised, hopefully having fixed up the exception. It is an icredibly naieve implementation, using unsupported data structures (meaning we are not going to promise to not change them on you from software update to software update), since we can safely update our exception management code in lockstep between our runtime and our kernels, and you can't, because you are unable to make simultaneous releases with no lag. We don't make those changes capraciously, but we do ocassionally make them. The implementation is naieve because there are actually 5 possible ucontext_t layouts on the PPC ISA, and you happened to pick the G4, meaning 32 bit PPC, which is relatively the most stable possible one, and one for which there was only a single layout. For Intel ISA, there are 5 possible layouts, and that's not including all the ones that were shipped as part of technology previews in WWDC builds (I will say that there have been at least 7). For you to build an exception handler in a signal handler that did exactly the same thing on Intel, you would need to distinguish at runtime which layout was being used, and then patch up the right locations. For the structures to have the right offsets and members, you would likewise have to use a particular compilation environment (which I will not note here, since it could be misinterpreted as documenting it). Finally, since some of the registers spilled could be used to thwart system security if their contents are modified, a shadow is kept in the kernel, and they are reset back to their previous values, ignoring whatever you do to them with signal stack hacking in user space. Finally, if you are using x87, Intel floating point exceptions are inexact (if you are on a 754 working group, you will already be painfully aware of this fact). Because of this, delayed delivery of exceptions via signal handlers (the signal trampoline generally fires as a result of an AST set on a Mach kernel thread state structure as a result of a unix system call return after running up to the user space/ kernel boundary, so it could be delayed considerably, just on Tru64 UNIX) can decouple the exception state at the time of the exception from the exception state you are trying to hack saved registers on the signal stack in order to fix up. So I will tell you what I have told others who are trying to fix up exceptions in their own runtimes: handle them as Mach exceptions, rather than using signal handlers. Obviously, I can't keep you from puzzling out the bits you would need to hack to deal with runtime recognition of which of the several contexts we use in the signal stack are used in yours, since we publish both our xnu sources and our gdb changes, but if you do, you're basically on your own, and shouldn't be surprised if at some software update in the future your code stops working, for the reasons listed above. On Sep 16, 2009, at 5:17 AM, "David N. Williams" <David.N.Williams(a)umich.edu > wrote: // static struct sigaction act = { myHandler, (sigset_t)0, SA_SIGINFO }; static struct sigaction act = { (void (*))myHandler, (sigset_t)0, SA_SIGINFO }; This email sent to site_archiver(a)lists.apple.com

1 0

Re: obcj4/CFLite on Windows
by Brent Fulgham 16 Sep '09

16 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9eLeX7kSOZLtACdh7qoyHvZffJjpVdVTtvnxlPfVERQ=; b=ovBtlmDYxXCMX72wPDspdwztKIOZFUUTFZxGvSlv2CFqVj75wJVU4iISd9T8+nLAXD t/P6ZgoBuvf/5JT555IlNBvJVEerIj0Jd2ilNCDl2iOCyb2DXXawSIwpwboo0iQAIRBe XrlFCl4cyNiEhZCI/Gac+lTcavBLJtJTj+fDA= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N4XlBQUHXBtY5Hqmi+1VuFjPEWVrMF9jWKmYKZzoHqspexw9vAIOkLgCJ166DKSfpe KK9jLUJEERxJBxph+8BkhLHhh01rK0KMs+dYUtnOG6C+Ewd5lWdNNCfdPLQ9obcT+qSp gIgj3l1cduuR0/hcHDo6PnTTkBXd0aiQfrDFQ= Hello Stuart, On Wed, Sep 16, 2009 at 4:04 AM, Stuart Crook <stuart(a)echus.demon.co.uk> wrote: > I think the short answer is the suggestion to disable Obj-C for CFLite. Look > at CFRuntime.c around line 468. That "#if 0" is new, and stops defining the > CFTYPE_ ... _OBJC macros as harmless. I think for all versions of OpenCFLite > you want to change it to use those first versions rather than the ones which > actually call into the obj-c runtime. I think this was the default behaviour > for building on non-OS X in previous versions. With CFLite prior to version 550, I would agree that this would work. However, if you look at the implementation of CFBag.c., CFDictionary.c, and CFSet.c you will see that the implementations of all three require access to the objc runtime (and Blocks!) to perform the hashing functions used to get/set information in the various data structures. I initially disabled Obj-C support, and even spent a few hours adding #if/def declarations around the new objc calls and block implementations (substituting in the old implementations), but eventually gave up. Looking over the CoreFoundation.dll that ships with Safari (on Windows) I noticed that it uses objc.dll, so the default behavior on Windows for 'real' CoreFoundation is to supply the objc support. Based on these two points, I think moving forward the road for Apple is to incorporate more Obj-C implementations in CoreFoundation, so I'm afraid this is a hurdle we have to get over. Thanks, -Brent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Floating-point exception handling
by David N. Williams 16 Sep '09

16 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: University of Michigan User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) I am part of an ad hoc group working on a Forth language standard for IEEE 754 (2008) floating point, and I'm trying to do an example implementation of alternate handling for floating- point exceptions with gcc/Darwin, for one of the C-based Forths. It's my first attempt at writing a signal handler, but I was able to get it working pretty well on my PowerPC G4, with the sample code quoted below as a guide. The sample code is apparently an update of Listing 7-1 in the 2004 version of "PowerPC Numerics". My question is, what's the analogous magic for OS X intel? AFAIU, there are two issues, enabling nondefault exception handling, and dealing with state in the handler. The sample code deals with state only by restoring it when the handler returns. I might be able to figure out the intel analog for the ppc assembly language functions used for enabling, fegetenvd() and fesetenvd() quoted below; but I wouldn't mind a little hand holding on that. I didn't find any documentation on what's going on with state restoration in myHandler(), and so don't have a clue how to change that for intel. Thanks for any suggestions. -- David ----------- /* The following sample code is slightly modified to get it to compile with gcc version 4.0.1 (Apple Inc. build 5493) under OS X 10.5.8 and ppc. The original is here: http://lists.apple.com/archives/unix-porting/2003/May/msg00026.html See also Listing 7-1 in "PowerPC Numerics", 2004: http://developer.apple.com/documentation/Performance/Conceptual/Mac_OSX_Num… -- David N. Williams, 15-Sep-09 */ #include <stdio.h> #include <math.h> #include <fenv.h> #include <signal.h> #include <ucontext.h> #include <mach/thread_status.h> #include <stdlib.h> // for exit() #define fegetenvd(x) asm volatile("mffs %0" : "=f" (x)); #define fesetenvd(x) asm volatile("mtfsf 255,%0" : : "f" (x)); enum { FE_ENABLE_INEXACT = 0x00000008, FE_ENABLE_DIVBYZERO = 0x00000010, FE_ENABLE_UNDERFLOW = 0x00000020, FE_ENABLE_OVERFLOW = 0x00000040, FE_ENABLE_INVALID = 0x00000080, FE_ENABLE_ALL_EXCEPT = 0x000000F8 }; typedef union { struct { unsigned long hi; unsigned long lo; } i; double d; } hexdouble; // void myHandler(int sig, siginfo_t *sip, struct ucontext *scp) void myHandler(int sig, siginfo_t *sip, ucontext_t *scp) { hexdouble t; // superfluous in this example ppc_float_state_t *fs; ppc_thread_state_t *ss; // fs = &scp->uc_mcontext->fs; fs = &scp->uc_mcontext->__fs; // ss = &scp->uc_mcontext->ss; ss = &scp->uc_mcontext->__ss; fprintf(stdout, "SIGFPE at 0x%x invokes myHandler, fpscr = %08X\n", // sip->si_addr, fs->fpscr); sip->si_addr, fs->__fpscr); // fs->fpscr &= FE_ENABLE_ALL_EXCEPT; fs->__fpscr &= FE_ENABLE_ALL_EXCEPT; // Re-arms interrupts when this state is restored // ss->srr0 += 4; // Advances the PC when this state is restored ss->__srr0 += 4; // Advances the PC when this state is restored // fprintf(stdout, "fpscr = %08X\n", fs->fpscr); fprintf(stdout, "fpscr = %08X\n", fs->__fpscr); fflush(stdout); } // static struct sigaction act = { myHandler, (sigset_t)0, SA_SIGINFO }; static struct sigaction act = { (void (*))myHandler, (sigset_t)0, SA_SIGINFO }; int main( int argc, char **argv) { float s; hexdouble t; fegetenvd(t.d); t.i.lo |= FE_ENABLE_ALL_EXCEPT; // Enable hardware trapping for all exceptions fesetenvd(t.d); if (sigaction(SIGFPE, &act, (struct sigaction *)0) != 0) { // Set handler perror("Yikes"); exit(-1); } fegetenvd(t.d); s = HUGE_VALF * HUGE_VALF; // Overflow folded out by compiler s = s / (1.0 + s); // Inf/Inf raises invalid operation fegetenvd(t.d); fprintf(stdout, "In main(1), s computed as: %e , fpscr = %08X\n", s, t.i.lo); // keep the compiler honest ... s = HUGE_VALF * HUGE_VALF; // Overflow folded out by compiler s = s / (2.0 + s); // Inf/Inf raises invalid operation fegetenvd(t.d); fprintf(stdout, "In main(2), s computed as: %e , fpscr = %08X\n", s, t.i.lo); // keep the compiler honest ... return 0; } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: obcj4/CFLite on Windows
by Stuart Crook 16 Sep '09

16 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, Brent. _sjc_ On 16 Sep 2009, at 07:44, Brent Fulgham wrote: Hi, 4. CFLite (550) crashes on startup. Therefore I assume my problem is in my CFLite build, and more specifically in the initialization logic. I realized that I was not linking the objcrt.obj into CFLite.dll. This got _objc_init_image to be called, so I guess that's some progress. However, the program continues to fail at the exact same spot. CFString.c: Line 1224: return CFRetain(kCFEmptyString); // Quick exit; won't catch all empty strings, but most Where kCFEmptyString is declared as: CFString.c: Line 152: CONST_STRING_DECL(kCFEmptyString, "") Thanks, -Brent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/stuart%40echus.demon.co.uk _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This is based on a quick scan through the CFLite 550 sources, so could be wrong. I think the short answer is the suggestion to disable Obj-C for CFLite. Look at CFRuntime.c around line 468. That "#if 0" is new, and stops defining the CFTYPE_ ... _OBJC macros as harmless. I think for all versions of OpenCFLite you want to change it to use those first versions rather than the ones which actually call into the obj-c runtime. I think this was the default behaviour for building on non-OS X in previous versions. To get the obj-c-CF bridge working, you need two things. On the CF side are the functions _CFRuntimeBridgeClasses and __CFISAForTypeID, which I'm amazed to discover are actually present in the CF source. (They we're missing in previous versions, so I had to patch them back in for PureFoundation). These basically set up the first long pointer of the CFType structure in exactly the same way as the NSObject ISA ivar, as a pointer to the class dispatch table. The second thing you need is some actual obj-c objects. Yeah :) The "Object" object which (used to, haven't checked) come with the obj-c runtime won't help. NSObject implements everything again from scratch, including the retain/release system. On OS X, CoreFoundation is definitely the junior member of the CF/Foundation partnership. As you can see from the CF code, whenever a function is called for a bridged object CF will try to dispatch a message to the Foundation/obj-c method before falling back on the CF code. (On OS X, NSObject and the bridged objects actually live inside the CoreFoundation library binary, rather than Foundation.framework.) But like I said above, for that to work you actually need some obj-c objects to be present. I think you get the crash because _CFISAForTypeID is being called in the creation method of every CFType and is copying junk from the bridge table, which hasn't been correctly populated. (Although -- and sorry, but I haven't had a chance to build and test this -- the table should just contain 0s, and you'd think the the runtime would take a NULL ISA as a hint to exit gracefully, but anyway...) So, yeah. CFLite doesn't need obj-c to work, so changing the definition of those macros should fix things. On Tue, Sep 15, 2009 at 6:27 PM, Brent Fulgham <bfulgham(a)gmail.com> wrote: The failure happens when attempting to call CFRetain on a static empty string CoreFoundation object: This email sent to stuart(a)echus.demon.co.uk This email sent to site_archiver(a)lists.apple.com

1 0

Re: obcj4/CFLite on Windows
by Brent Fulgham 16 Sep '09

16 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=NkNyCnXwYQrq4RLjzHwBZA7Rs7YZkBr12wJcRk8jkl8=; b=Q9FtiZaWK6TerF8VQA1OnzjWB6pzAiCW0eyhoLEe8u4kWeHX5KK6zrtkJq1tLrzf9/ GNKyj0x0e7CSHkDiXCLzpy04vAPI8OBYfGQjry4QJnI1J+pgkVkPZkFEahXpUng8keGA 3cRsrbLm+hVC6BfB9akFAew9Xoiq53dP31lis= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qNzvTj4lgaSozzpnvZMmGpHvpTt5kaX23nkSXTozXrQW2/8MepB4ZL90R0AxaG6Xew iS7Sk/UxnJV6dEajOLFevvmn/WCNdZmlHesW72cXUw4GZibDCprFAkKSgND5rzW3+UOq A4UGQvO0Mzlhpi+wjEf6eqIndrns/KJY7eHKo= Hi, On Tue, Sep 15, 2009 at 6:27 PM, Brent Fulgham <bfulgham(a)gmail.com> wrote: > 4. CFLite (550) crashes on startup. > > Therefore I assume my problem is in my CFLite build, and more > specifically in the initialization logic. I realized that I was not linking the objcrt.obj into CFLite.dll. This got _objc_init_image to be called, so I guess that's some progress. However, the program continues to fail at the exact same spot. > The failure happens when attempting to call CFRetain on a static empty > string CoreFoundation object: > > CFString.c: Line 1224: > return CFRetain(kCFEmptyString); // Quick exit; won't catch all > empty strings, but most > > Where kCFEmptyString is declared as: > > CFString.c: Line 152: > CONST_STRING_DECL(kCFEmptyString, "") Thanks, -Brent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0