November 2005 - Darwin-dev - lists.apple.com

Re: Possible poor use of __ppc__, __ppc64__ and __i386__ in CFRuntime.h
by Emil Petersson 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com typedef struct __CFRuntimeBase { void *_isa; uint16_t _rc; uint16_t _info; } CFRuntimeBase; And the INIT macro for PPC: #define INIT_CFRUNTIME_BASE(isa, info, rc) { isa, info, rc } Emil On 21 nov 2005, at 22.29, Kevin Van Vechten wrote: Agreed, this is really a big/little endian check. - Kevin On Nov 21, 2005, at 12:41 PM, Shawn Erickson wrote: I was poking around in Core Foundation for unrelated reasons and came across the following code in CFRuntime.h [1] in the 10.4.3 version of things (CF-368.18). typedef struct __CFRuntimeBase { void *_isa; #if defined(__ppc__) || defined(__ppc64__) uint16_t _rc; uint16_t _info; #elif defined(__i386__) uint16_t _info; uint16_t _rc; #else #error unknown architecture #endif } CFRuntimeBase; #if defined(__ppc__) || defined(__ppc64__) #define INIT_CFRUNTIME_BASE(isa, info, rc) { isa, info, rc } #elif defined(__i386__) #define INIT_CFRUNTIME_BASE(isa, info, rc) { isa, rc, info } #else #error unknown architecture #endif -Shawn _______________________________________________ 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… Also, the INIT macro seems to initialize the members out of order (if the code below is correct). On PPC the structure would become: Seems wrong to me. Can't say if the error is in the struct or the macro though. It looks like an endian specific compile time check... if so I believe it is better to check for __BIG_ENDIAN__ (and possibly also __LITTLE_ENDIAN__) in the above instead of checking processor type macros. If others agree I will file a defect. [1] <http://darwinsource.opendarwin.org/10.4.3/CF-368.18/ Base.subproj/CFRuntime.h> This email sent to site_archiver(a)lists.apple.com

1 0

Re: Possible poor use of __ppc__, __ppc64__ and __i386__ in CFRuntime.h
by Kevin Van Vechten 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ 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

Possible poor use of __ppc__, __ppc64__ and __i386__ in CFRuntime.h
by Shawn Erickson 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=t3qnqyUhsvS0sXajpFb9z0jaR0uzaiSKZ07M4Giz4YdAThZkCz3tcfNQratysedOMwS/bLzPmbRDIMcmoq0EcrfrIYWtx1obxtxtbtYrGxQfKi+JCMAdU3r9jV4RZF6F0z5FfH5fp0foWG0Z3Zv1/wgUdwv0jPMvQXrM+R0HAUQ= I was poking around in Core Foundation for unrelated reasons and came across the following code in CFRuntime.h [1] in the 10.4.3 version of things (CF-368.18). typedef struct __CFRuntimeBase { void *_isa; #if defined(__ppc__) || defined(__ppc64__) uint16_t _rc; uint16_t _info; #elif defined(__i386__) uint16_t _info; uint16_t _rc; #else #error unknown architecture #endif } CFRuntimeBase; #if defined(__ppc__) || defined(__ppc64__) #define INIT_CFRUNTIME_BASE(isa, info, rc) { isa, info, rc } #elif defined(__i386__) #define INIT_CFRUNTIME_BASE(isa, info, rc) { isa, rc, info } #else #error unknown architecture #endif It looks like an endian specific compile time check... if so I believe it is better to check for __BIG_ENDIAN__ (and possibly also __LITTLE_ENDIAN__) in the above instead of checking processor type macros. If others agree I will file a defect. -Shawn [1] <http://darwinsource.opendarwin.org/10.4.3/CF-368.18/Base.subproj/CFRuntime.h> _______________________________________________ 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: catching EXC_BAD_ACCESS?
by Jordan K. Hubbard 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ 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: catching EXC_BAD_ACCESS?
by Brad Parker 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: Heeltoe Consulting Jonas Maebe wrote: > >On 21 nov 2005, at 15:43, Jonas Maebe wrote: > >> I've now tried a 64bit version and sure enough, that one always >> crashes with a SIGBUS when returning from the signal handler, even >> if the handler doesn't do anything. Warrants a radar, I'd say. I've >> put the adjusted 64bit version of the test program below (which, as >> I said, crashes even if you remove all code from "signal_handler"): > >Found the solution! Change > >> sa.sa_flags = SA_SIGINFO; > >into > >sa.sa_flags = SA_SIGINFO|SA_64REGSET; heh. I added that to my FPE test program and the machine hung hard. I had to power cycle :-) it's a imac G5. -brad _______________________________________________ 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: How to find out if running on new dual core G5
by Dave Yost 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com At 10:11 AM -0800 2005-11-18, Dave Zarzycki wrote: >The following sysctl variables will probably be useful to you then: > >* hw.ncpu - The maximum number of processors that could be available this boot. >* Use this value for sizing of static per processor arrays; i.e. processor load statistics. >* >* hw.activecpu - The number of processors currently available for executing threads. >* Use this number to determine the number threads to create in SMP aware applications. >* This number can change when power management modes are changed. >* >* hw.physicalcpu - The number of physical processors available in the current power management mode. >* hw.physicalcpu_max - The maximum number of physical processors that could be available this boot >* >* hw.logicalcpu - The number of logical processors available in the current power management mode. >* hw.logicalcpu_max - The maximum number of logical processors that could be available this boot The above has variables not shown in the man page and has descriptions that should be shown on the man page. Dave _______________________________________________ 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: catching EXC_BAD_ACCESS?
by Peter O'Gorman 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Maebe wrote: | | PS: is it expected that "otool -L" fails on 64 bit programs? I get use otool64 -L Yes, I know... Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ4HidLiDAg3OZTLPAQJpVwP/TbP0HGMLBKGSFuGawbEUnpnzcmIAkxrZ KQ7lzZLh1wudaWHz8/0EE0/4W2jmZ4snAmn4F4N6hpZxMoQL72hZ8WWZgvplpf9f py3woEaJ9Wbe5PlorWbSOmlIqPJuzueHPGkqAHGdk3Bde+rdBxmX8c7ov1zpaCP6 tRi7Fth4oO4= =4XgA -----END PGP SIGNATURE----- _______________________________________________ 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: catching EXC_BAD_ACCESS?
by Jonas Maebe 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 21 nov 2005, at 15:43, Jonas Maebe wrote: Found the solution! Change into sa.sa_flags = SA_SIGINFO|SA_64REGSET; Now the program I posted works fine when compiled for 64bit. Jonas PS: is it expected that "otool -L" fails on 64 bit programs? I get $ file sig4 sig4: Mach-O 64-bit executable ppc64 $ otool -L sig4 sig4: is not an object file _______________________________________________ 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've now tried a 64bit version and sure enough, that one always crashes with a SIGBUS when returning from the signal handler, even if the handler doesn't do anything. Warrants a radar, I'd say. I've put the adjusted 64bit version of the test program below (which, as I said, crashes even if you remove all code from "signal_handler"): sa.sa_flags = SA_SIGINFO; The comments in /usr/include/sys/signal.h say SA_64REGSET is only necessary to get access to the 64bit registers when you're in 32bit mode, but apparently it's also required for 64bit mode (or do you have to use another option besides -m64 to get a "proper" 64bit program?) This email sent to site_archiver(a)lists.apple.com

1 0

Re: catching EXC_BAD_ACCESS?
by Jonas Maebe 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 21 nov 2005, at 14:53, Brad Parker wrote: At least on Mac OS X, the init code of libc doesn't turn on (or possibly explicitly turns off) all FPU exceptions. If you turn them on, you can catch SIGFPE's as much as you like. At least for 32 bit programs SA_SIGINFO works fine for SIGFPE. It also seems that changes to the thread state (via args passed to the signal handler) are ignored. *** #include <signal.h> #include <stdio.h> #include <ucontext.h> // check whether we really caught the exception static int caught = 0; typedef void (*__sighandler_t)(); void install_signal_handler(int signo, __sighandler_t handler) { struct sigaction sa; sa.sa_handler = (void *)handler; sigemptyset(&sa.sa_mask); // needed for the ucontext parameter to be available sa.sa_flags = SA_SIGINFO; sigaction(signo, &sa, NULL); } int main() { double a,b,c; // install the handler for SIGFPE install_signal_handler(SIGFPE, signal_handler); // enable FPU exceptions for fpu division by zero, fpu underflow, fpu // overflow and fpu invalid operation asm volatile("mtfsfi 6,15"); b = 1.0; c = 0.0; // trigger an exception caught = 0; a = b/c; printf("caught 1: %d\n",caught); // trigger another exception caught = 0; a = b/c; printf("caught 2: %d\n",caught); return 0; } *** Jonas _______________________________________________ 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… [note - my comments apply only to 64 bit applications. I don't know what happens for 32 bit apps] Yes, turning on the fp exception is the easy part. And, the signal handler gets called. But two problems exist. One is that if sa_flags = SA_SIGINFO it crashes. It only seems to work if sa_flags is zero. But if you want the thread state sa_flags needs to be SA_SIGINFO. In other 64 bit "unix-like systems" (read linux), you can change srr0 in the signal handler and return, changing the flow of the original code. This doesn't work for me in OS X. Works fine in 32bit mode for me. See this message (and the two follow- ups by me) for more info and a sample program: http://lists.apple.com/archives/darwin-development/2004/Jan/ msg00018.html Note that Safari here gives a ton of "NSURLErrorDomain:-1005" errors when trying to go there, just keep reloading until it gets through. I've now tried a 64bit version and sure enough, that one always crashes with a SIGBUS when returning from the signal handler, even if the handler doesn't do anything. Warrants a radar, I'd say. I've put the adjusted 64bit version of the test program below (which, as I said, crashes even if you remove all code from "signal_handler"): void signal_handler(int signum, siginfo_t *info, ucontext64_t* sigcontext) { caught = 1; // Skip over faulting instruction sigcontext->uc_mcontext64->ss.srr0 += 4; // turn off all "exception occurred" flags in fpscr sigcontext->uc_mcontext64->fs.fpscr &= ~(0xfffc0000); } This email sent to site_archiver(a)lists.apple.com

1 0

Re: catching EXC_BAD_ACCESS?
by Brad Parker 21 Nov '05

21 Nov '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: Heeltoe Consulting Jonas Maebe wrote: > >On 31 okt 2005, at 02:50, Brad Parker wrote: > >> (I also, believe it or not, want to catch EXC_ARITHMETIC, which >> doesn't seem to get mapped to SIGFPE) > >At least on Mac OS X, the init code of libc doesn't turn on (or >possibly explicitly turns off) all FPU exceptions. If you turn them >on, you can catch SIGFPE's as much as you like. [note - my comments apply only to 64 bit applications. I don't know what happens for 32 bit apps] Yes, turning on the fp exception is the easy part. And, the signal handler gets called. But two problems exist. One is that if sa_flags = SA_SIGINFO it crashes. It only seems to work if sa_flags is zero. But if you want the thread state sa_flags needs to be SA_SIGINFO. It also seems that changes to the thread state (via args passed to the signal handler) are ignored. In other 64 bit "unix-like systems" (read linux), you can change srr0 in the signal handler and return, changing the flow of the original code. This doesn't work for me in OS X. I realize it's Mach underneath, and I've since written a Mach exception handler. This is a nice facility but a little heavy weight for what I am doing (still, it seems to work). -brad _______________________________________________ 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