August 2009 - Darwin-dev - lists.apple.com

Re: Mac OS X Snow Leopard and 64-bit applications
by Terry Lambert 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Maybe people should quit using configure entirely. Just saying... -- Terry On Aug 30, 2009, at 3:04 PM, Dmitry Markman <dmarkman(a)mac.com> wrote: that's actually exactly the problem for gcc 4.4.1 because config.guess doesn't guess correctly :-) it returns i386-apple-darwin10.0.0 and configure fails miserably unless I provide host, build and target arguments explicitly as x86_64-apple-darwin10.0.0 On Aug 30, 2009, at 5:59 PM, Mo McRoberts wrote: I’d be curious to know what would break if uname returned the user-space architecture (as targeted by the system compiler by default) rather than the kernel architecture. M. -- http://nevali.net Dmitry Markman _______________________________________________ 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/tlambert%40apple.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… On Sun, Aug 30, 2009 at 21:26, Brian Bechtel<brian.bechtel(a)gmail.com> wrote: Arch and uname -p both return the processor family type, i386. (as opposed to ppc or arm.) I think the rationale was that too many scripts depend upon this behavior. This actually doesn’t make a huge amount of sense: something like config.guess will return 'i386-apple-darwin10.0.1', despite the fact that gcc will be (by default) targeting x86_64; anything which relies on the knowledge that "i386" is by default entirely 32-bit will therefore break. In contrast, most other x86_64 systems tend to be set up such that x86_64 is reported as the “system” architecture (wh ere the kernel architecture is pretty incidental), and so you have a triplet of, say, x86_64-pc-linux-gnu. This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Terry Lambert 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Aug 30, 2009, at 1:21 PM, Terry Lambert wrote: No hypervisor required. -- Terry _______________________________________________ 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… On Aug 30, 2009, at 2:53 PM, Brian Mastenbrook <brian(a)mastenbrook.net> wrote: Actually it is because the NVRAM driver is built in the EFI. Not that I have any reason to actually want K64, but I wonder what the overhead of using a small hypervisor to virtualize access to the NVRAM would be. Thanks to the VT extensions it's perfectly possible to run a 64-bit kernel under a 32-bit hypervisor in this fashion. It would be possible to thunk it. The 32 bit kernel runs its trap and page code 64 bit so that we can support 64 bit processes, and switches to compatibility mode for running the 32 bit kernel. If you want to provide patches, I have an early MacBook Pro that would appreciate it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: process exit status from kevent
by Terry Lambert 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com -- Terry On Aug 30, 2009, at 1:07 PM, Ameen <alameenshah(a)gmail.com> wrote: kevent.data holds 0x0 on the Mac. am i missing something here or is it the way it is ? would appreciate any pointers. Thanks, Ameen. _______________________________________________ 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/tlambert%40apple.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… File an enhancement request/bug report vs. BSD kernel and I'll take care of it. while monitoring the exit of an unrelated ( not parent child relationship ) process using kqueue - EVFILT_PROC - NOTE_EXIT, it would have been very convenient to fetch its exit status as well, like the way it is possible in FreeBSD (http://www.freebsd.org/cgi/man.cgi?query=kevent&apropos=0&sektion=0&manpath… ) man pages for kqueue/kevent does not mention anything about getting the exit status from NOTE_EXIT. This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Mo McRoberts 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mon, Aug 31, 2009 at 16:29, Esteban Bodigami<esteban.bodigami(a)gmail.com> wrote: > As I don't buy buildings (architettura) without "planos"; I won't buy > software without the source. I want "Mac OS X API" (Cocoa or Carbon; > for practical purposes they are the same... btw, Java support in > Macintosh is crap) for OpenSolaris, the other *BSDs and Gnu/KDE/Linux. > It is like buying a house without the "source" to the pipelines (of > water, electricity, wired internet). > > 64 bit won... but I am not sure of the long-term prospects of x86. The > number of cores is the new easily recognizable CPU tech spech; and > OpenSPARC beat both AMD and Intel with 8 cores (AND you can build your > own Niagara CPU... if you have a "Forge"). I prefer Risc, and this > multiCore Era will bring back (hopefully) a discussion about Risc and > Cisc CPU architecture designs. How, exactly, is this on-topic? M. -- http://nevali.net _______________________________________________ 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: Mac OS X Snow Leopard and 64-bit applications
by Mo McRoberts 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mon, Aug 31, 2009 at 14:31, Esteban Bodigami<esteban.bodigami(a)gmail.com> wrote: > I have always used uname to know the UNIX NAME of the OS, that means > the version and name of the Unix/POSIX OS... not the architecture. > Unix was coded in C to make the architecture irrelevant (however, > software was usually distributed in .c ...now it will probably be a > pre'compiled binary of w-e "Unix distro you are using). No. > It is a matter of time before Mac OS X becomes fully open source, > however Apple should focus more in "translating the high % of mind > share to high % of market share". Hint: few care if the MacBook Air is > thiner than "all" the other portable computers, the netBooks are > winning because of PRICE. I’m pretty sure Apple is doing better than most PC manufacturers right now. -- http://nevali.net _______________________________________________ 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: Mac OS X Snow Leopard and 64-bit applications
by Mo McRoberts 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mon, Aug 31, 2009 at 13:33, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: > Mo McRoberts wrote: > >> therefore break. In contrast, most other x86_64 systems tend to be set >> up such that x86_64 is reported as the “system” architecture (where >> the kernel architecture is pretty incidental), and so you have a >> triplet of, say, x86_64-pc-linux-gnu. > > Where most is linux? Nobody can really even agree if its > amd64 or x86_64, much less what uname is supposed to say. > For example, here's FreeBSD/amd64: > > % uname -a > FreeBSD thor 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r196400: Thu Aug 20 09:38:12 EDT > 2009 gallatin@thor:/usr/src/sys/amd64/compile/THOR amd64 > % uname -p > amd64 > > Once you translate amd64 to x86_64, it behaves the way you'd expect. > gcc defaults to producing 64-bit binaries. Replace “FreeBSD” with “the BSDs [excepting Darwin]” Indeed; you _can_ conclusively translate amd64 to x86_64. You can't do the same for i386, because it’s ambiguous. As you say, OpenSolaris is similarly irritating, though it produces binaries by default matching the detected architecture so it’s not a problem in practice. If either of (a) the developer tools on Mac OS X produced i386 binaries by default (which wouldn’t affect Xcode, as it always explicitly specifies) or (b) something was output (by uname, arch, whatever) which told semi-recent versions of config.guess that the default arch was x86_64 and not i386, the problem would go away as far as I can see. M. -- http://nevali.net _______________________________________________ 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: Mac OS X Snow Leopard and 64-bit applications
by Andrew Gallatin 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.22 (X11/20090608) Mo McRoberts wrote: therefore break. In contrast, most other x86_64 systems tend to be set up such that x86_64 is reported as the “system” architecture (where the kernel architecture is pretty incidental), and so you have a triplet of, say, x86_64-pc-linux-gnu. Where most is linux? Nobody can really even agree if its amd64 or x86_64, much less what uname is supposed to say. For example, here's FreeBSD/amd64: Once you translate amd64 to x86_64, it behaves the way you'd expect. gcc defaults to producing 64-bit binaries. And here is OpenSolaris i86pc: % uname -a SunOS dell1435a 5.11 snv_111a i86pc i386 i86pc % uname -p i386 On Solaris, you use an obscure command (isainfo) to tell you what instruction set is supported: % isainfo -n amd64 But gcc (and sunpro) produce 32-bit binaries by default. % touch t.c % gcc -c t.c % file t.o t.o: ELF 32-bit LSB relocatable 80386 Version 1 % gcc -m64 -c t.c % file t.o t.o: ELF 64-bit LSB relocatable AMD64 Version 1 So I really don't think MacOSX is any more confusing than anything else.. Cheers, Drew _______________________________________________ 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… % uname -a FreeBSD thor 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r196400: Thu Aug 20 09:38:12 EDT 2009 gallatin@thor:/usr/src/sys/amd64/compile/THOR amd64 % uname -p amd64 This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Jean-Daniel Dupas 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 30 août 2009 à 23:53, Brian Mastenbrook a écrit : On Aug 30, 2009, at 1:21 PM, Terry Lambert wrote: _______________________________________________ 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… Actually it is because the NVRAM driver is built in the EFI. Not that I have any reason to actually want K64, but I wonder what the overhead of using a small hypervisor to virtualize access to the NVRAM would be. Thanks to the VT extensions it's perfectly possible to run a 64-bit kernel under a 32-bit hypervisor in this fashion. Good reason, but it does not explain why MacBookPro3,1 which has 64 bit EFI are not bootable using the 64 bit Kernel. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Vincent Lubet 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Aug 28, 2009, at 11:43 PM, rohan a wrote: Now with the 10.6 Snow Leopard kernel being full 64-bit, will it require all applications to also be 64-bit ?Our application does not need to address > 4GB memory. We had developed a 32-bit application for Mac OS X 10.4 and 10.5. Would the same work on 10.6 without any changes or would it require to be recompiled for 64-bit ? No, you don't have to recompile, your 32-bit app should just work. Yes, it does Vincent _______________________________________________ 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'm not I have seen straight answers to Rohan's question in this thread... In SnowLeopard, the 64-bit kernel supports 32-bit and 64-bit processes just as the 32-bit kernel does. Will Mac OS X gcc compiler on Snow Leopard natively build 64-bit binaries ? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Dmitry Markman 30 Aug '09

30 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com that's actually exactly the problem for gcc 4.4.1 because config.guess doesn't guess correctly :-) it returns i386-apple-darwin10.0.0 and configure fails miserably unless I provide host, build and target arguments explicitly as x86_64-apple-darwin10.0.0 On Aug 30, 2009, at 5:59 PM, Mo McRoberts wrote: This actually doesn’t make a huge amount of sense: something like config.guess will return 'i386-apple-darwin10.0.1', despite the fact that gcc will be (by default) targeting x86_64; anything which relies on the knowledge that "i386" is by default entirely 32-bit will therefore break. In contrast, most other x86_64 systems tend to be set up such that x86_64 is reported as the “system” architecture (where the kernel architecture is pretty incidental), and so you have a triplet of, say, x86_64-pc-linux-gnu. I’d be curious to know what would break if uname returned the user-space architecture (as targeted by the system compiler by default) rather than the kernel architecture. M. -- http://nevali.net Dmitry Markman _______________________________________________ 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… On Sun, Aug 30, 2009 at 21:26, Brian Bechtel<brian.bechtel(a)gmail.com> wrote: Arch and uname -p both return the processor family type, i386. (as opposed to ppc or arm.) I think the rationale was that too many scripts depend upon this behavior. This email sent to site_archiver(a)lists.apple.com

1 0