February 2006 - Darwin-dev - lists.apple.com

bug in gcc 4.0.1/5250/i386
by Scott Smith 24 Feb '06

24 Feb '06

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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sGK1Jb+9QaFiOhAZzuR8TQn56Cme8RmtF+dYsdUT+nG4QkskP4qeKBE4B7Ht+KlO8shUzLNmIQgl7I7qEXE+wJDPnQOzs85NlXaRANbG2ZBQV4cihc1vTlqnqVK5VATz/EU/NJ72JUhRYdSI+KLFbEzxXPAnlnQQAY+rFFRfnpM= There is a bug in the gcc optimizer that only shows up with the darwin build, not on the 4.0.1 I download from gnu and use on a non-mac. The following C code snippet: #include <inttypes.h> #include <stdlib.h> #define ALIGN_PTR(p,a) ((void *)( (((size_t)(p))+(a)-1)&~((size_t)(a)-1))) void *foo(void) { float x[13]; return ALIGN_PTR(x,16); } is designed to align 'x' on a 16-byte boundary. This code is for illustrative purposes only (I know you can't return local variables from a function, and if you align a array of 13 4-byte elements, the most you can use is 10 elements)... etc. The problem is that with '-O1', gcc will discard the alignment instructions. I figured out that gcc is using '-mpreferred-stack-boundary=4' to assume the stack frame is automatically aligned on a 16-byte boundary. That's great, however that says nothing about the variables declared inside the stack frame. In this case, 'x' is only aligned on a 4-byte boundary, not 16-byte. I can fix this one of two ways: using '-mpreferred-stack-boundary=2' will cause gcc to emit the correct code, however that causes other problems (called functions will no longer able to assume a nice stack alignment). The other way is to add '__attribute__((aligned(16)))'. Since the stack frame is already aligned, gcc can force the alignment of the variable for me. The real problem is that gcc should not assume that the variable is aligned in the first place! Is this the right place for the bug report, or should I forward it somewhere else? -- Scott _______________________________________________ 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

symbol_stubs on x86
by Cyrus Harmon 24 Feb '06

24 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks, Cyrus _______________________________________________ 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 trying to port a piece of software from ppc to x86. This program uses a symbol_stub and .indirect_symbol to lazily bind a function to call at runtime, following the approach on p. 33 of the MacOS X Assembler Guide. Does anyone know of a similar example for x86? I'm too knew to x86 assembly language (and the MacOS Assembler in general) to figure out how to do the same thing for x86. This email sent to site_archiver(a)lists.apple.com

1 0

RE: usefulness of source
by Bill Lowrey 24 Feb '06

24 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: istation Thread-index: AcY49Fs0Lrq51/k3QlWYUDypDlEkkAAb4sIg >> >> Profit motive, not OCD, I assure you ;-). > Second that. Especially because kernel documentation is nonexistent, > the source is necessary for driver development. (Although I've long > wondered whether making the source available was just an excuse to > avoid providing adequate kernel documentation.) I'll third it :). I had no way of figuring out why some sysctl calls weren't working until I saw the code returning ENOTSUP, and the conditions that it returned that value. The man pages certainly said they should work... Bill -----Original Message----- From: darwin-dev-bounces+billl=istation.com(a)lists.apple.com [mailto:darwin-dev-bounces+billl=istation.com@lists.apple.com] On Behalf Of Chris Thomas Sent: Thursday, February 23, 2006 9:42 PM To: darwin-dev(a)lists.apple.com Subject: Re: usefulness of source On Feb 23, 2006, at 10:38 AM, Amanda Walker wrote: > On Feb 22, 2006, at 9:01 PM, Rob Braun wrote: >> Do people actually do anything with the >> source, or just have an obsessive compulsive disorder to >> continually check for it? > > On several occasions, access to the source (including xnu, which > I'm hoping will show up) has been the only way I've been able to > track down the info I've needed to rev hardware device drivers for > new versions of MacOS X. > > Profit motive, not OCD, I assure you ;-). Second that. Especially because kernel documentation is nonexistent, the source is necessary for driver development. (Although I've long wondered whether making the source available was just an excuse to avoid providing adequate kernel documentation.) Also, to add to Dave Leimbach's point: > Point is, we more technically savvy geeks even had *fun* with this > stuff when it was more enabled. Now the only project we've got > that's even close to like this anymore is Webkit, and I suspect > that's because Apple really does need to get along with the KDE > hackers for this to continue. Perhaps it's more of a political > strength or a goodwill thing because they've chosen to work closely > with that community (and have received bad press in the past about > it too). Apple could've ignored the complaints of the KDE hackers and proceeded along their own solitary path, much as they did with the kernel. But they chose differently, and they're reaping the rewards: > We've received contributions in every area of WebKit. Here are just > a few of the improvements made by non-Apple contributors: > > The entire webkit.org infrastructure, including nightly builds and > the buildbot. > JavaScriptCore that matches up with KJS. > Many fixes that were formerly only in KHTML and KJS in the KDE > source tree. > SVG support in WebKit. > Improved structure of DOM and auto-generated bindings inspired by > KDOM. > Vast text layout and rendering improvements, including excellent > right-to-left support. > A tremendous number of bug fixes that were easy because of > reductions, excellent test cases, and pinpointed version numbers > for regressions. Chris _______________________________________________ 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/billl%40istation.com This email sent to billl(a)istation.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: usefulness of source
by Graham J Lee 24 Feb '06

24 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5 (Macintosh/20051201) On Feb 23, 2006, at 10:38 AM, Amanda Walker wrote: -- Graham Lee UNIX Systems Manager, Oxford Physics Practical Course http://users.ox.ac.uk/~wadh1342 _______________________________________________ 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 24/2/06 03:42, Chris Thomas wrote: Profit motive, not OCD, I assure you ;-). Second that. Especially because kernel documentation is nonexistent, the source is necessary for driver development. (Although I've long wondered whether making the source available was just an excuse to avoid providing adequate kernel documentation.) At one point (and it may indeed still be the case) Apple were soliciting third-party headerdoc, manpages and HOWTOs for Darwin including KPI documentation. IIRC they even had an email address set up for submissions. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Protected Memory
by Pelle Johansson 24 Feb '06

24 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com (resent from correct address) 24 feb 2006 kl. 00.38 skrev Tomas Zahradnicky: Why would you need to do that? _______________________________________________ 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 had a program under OS 9 that could be used to do this (mostly to cheat at games :) That programs usually didn't dare to just write and used undocumented APIs from PrivateInterfaceLib instead. Most modern operating systems do not allow one application to access memory of another application (apart from shared memory which requires the processes to cooperate). Well, most modern OSes allow you to do it through the VM APIs and you can map a portion of one process's virtual address space into your own process's address space where you can change it and possibly write it back if you have the enough privileges to do so, of course. Someone already wrote a version of The Cheat to Mac OS X. You can probably use it as reference. It's available with source at <http:// www.brokenzipper.com/> (GPL licenced). -- Pelle Johansson This email sent to site_archiver(a)lists.apple.com

1 0

Re: usefulness of source
by Chris Thomas 24 Feb '06

24 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 23, 2006, at 10:38 AM, Amanda Walker wrote: Do people actually do anything with the source, or just have an obsessive compulsive disorder to continually check for it? Also, to add to Dave Leimbach's point: Chris _______________________________________________ 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 Feb 22, 2006, at 9:01 PM, Rob Braun wrote: On several occasions, access to the source (including xnu, which I'm hoping will show up) has been the only way I've been able to track down the info I've needed to rev hardware device drivers for new versions of MacOS X. Profit motive, not OCD, I assure you ;-). Second that. Especially because kernel documentation is nonexistent, the source is necessary for driver development. (Although I've long wondered whether making the source available was just an excuse to avoid providing adequate kernel documentation.) Point is, we more technically savvy geeks even had *fun* with this stuff when it was more enabled. Now the only project we've got that's even close to like this anymore is Webkit, and I suspect that's because Apple really does need to get along with the KDE hackers for this to continue. Perhaps it's more of a political strength or a goodwill thing because they've chosen to work closely with that community (and have received bad press in the past about it too). Apple could've ignored the complaints of the KDE hackers and proceeded along their own solitary path, much as they did with the kernel. But they chose differently, and they're reaping the rewards: We’ve received contributions in every area of WebKit. Here are just a few of the improvements made by non-Apple contributors: The entire webkit.org infrastructure, including nightly builds and the buildbot. JavaScriptCore that matches up with KJS. Many fixes that were formerly only in KHTML and KJS in the KDE source tree. SVG support in WebKit. Improved structure of DOM and auto-generated bindings inspired by KDOM. Vast text layout and rendering improvements, including excellent right-to-left support. A tremendous number of bug fixes that were easy because of reductions, excellent test cases, and pinpointed version numbers for regressions. This email sent to site_archiver(a)lists.apple.com

1 0

Re: usefulness of source
by Bill Northcott 24 Feb '06

24 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Bill Northcott _______________________________________________ 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 24/02/2006, at 7:03 AM, darwin-dev-request(a)lists.apple.com wrote: It makes me sad to not be back in the good old days (which apparently were even more good before I came into this picture) but time moves on, relationships change and the way I work with Mac OS X has as well. I've really gone back to linux and FreeBSD and other far more esoteric operating systems for my OS experimentation fun. Just as Apple seemingly left me behind, I've moved on as well. I think this is bit like the time that Scott McNealy said something like "You have no privacy. Get over it." I still think it's a bit of a shame but Apple's a business and needs to do what they think is right for them and their stakeholders first. I have my suspicions that what is the core of all this is Hollywood and the record companies, who seem to have persuaded the US legislature to enact pernicious legislation the sole purpose of which is to greatly increase the profits of the large multi nationals that control entertainment. Going forward, if Apple want to continue to produce systems that handle vision and music, they will need to have DRM (Digital Restrictions Management) built into the core of the system including but not limited to the kernel. Of course they have some self-interest here: not wanting MacOS to run on ordinary PCs, although that could probably have been done at a higher level in proprietary code which has never been part of Darwin. They are presumably not going to bother with this for the PPC hardware which is why there is no problem with those sources. However, to release the x86 sources, they need a methodology to strip any DRM related code out before release. This is presumably a non- trivial task. Hence the delay. Apple don't want to be seen as having leaked vital information for hackers. Ars Technica had a really good article this week berating the computer and home entertainment industries for putting up with all this strife from a content industry that is a fraction of their size. After all the hardware companies could club together and go into business making content. They could pay the artists more and release products free of mindless DRM junk. I reckon that might bring Hollywood into line. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Protected Memory
by Steve Checkoway 23 Feb '06

23 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Which is how the debugger does it. - Steve _______________________________________________ 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 On Feb 23, 2006, at 3:38 PM, Tomas Zahradnicky wrote: Anyway, my secondary question is: can one application access another's memory? In general, the answer is no; however, the debugger is able to do so. ptrace can be used too. smime.p7s

1 0

Re: Protected Memory
by Tomas Zahradnicky 23 Feb '06

23 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Why would you need to do that? ptrace can be used too. Tomas -- # Ing. Tomas Zahradnicky, Jr. # The Czech Technical University # Dept of Computer Science, FEE-CTU Prague _______________________________________________ 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 had a program under OS 9 that could be used to do this (mostly to cheat at games :) That programs usually didn't dare to just write and used undocumented APIs from PrivateInterfaceLib instead. Most modern operating systems do not allow one application to access memory of another application (apart from shared memory which requires the processes to cooperate). Well, most modern OSes allow you to do it through the VM APIs and you can map a portion of one process's virtual address space into your own process's address space where you can change it and possibly write it back if you have the enough privileges to do so, of course. Anyway, my secondary question is: can one application access another's memory? In general, the answer is no; however, the debugger is able to do so. This email sent to site_archiver(a)lists.apple.com

1 0

Re: usefulness of source
by Timothy J. Wood 23 Feb '06

23 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 22, 2006, at 6:01 PM, Rob Braun wrote: I'm curious, it seems there are more people here enjoying gloating over those that were anxious for the source than there are people actually using it. And that's what I'm really curious about, has anyone found the source posted to be particularly useful? Now that the source has been out for a full day, and all those that have been chomping on the bit to get it finally have it, I haven't seen anyone post success or failure stories with what they're doing, other than my own dismal failure due to the lack of xnu headers/source. Do people actually do anything with the source, or just have an obsessive compulsive disorder to continually check for it? -tim _______________________________________________ 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… OmniObjectMeter has benefited greatly from the availability of source for malloc, CF-lite, Csu, dyld, gdb, and the Objective-C runtime. I've also used the xnu source as the final word on how some of the Mach APIs work. This email sent to site_archiver(a)lists.apple.com

1 0