March 2013 - Darwin-kernel - lists.apple.com

RE: Query related to lookup
by Pratima Kudale 28 Mar '13

28 Mar '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Lend Me a Kernel?
by Michael Crawford 28 Mar '13

28 Mar '13

I forgot to say, it's a 10.6.8 Snow Leopards Kernel. It's forced to 32-bit only because I'm running on a MacBookPro1,1. On Thu, Mar 28, 2013 at 12:39 PM, Michael Crawford <mdcrawford(a)gmail.com> wrote: > Friends, > > I accidentally deleted my kernel a while back, and have been unable to > find a replacement. My problem is that my Mac is a 32-bit machine, > which is way out of style. By any chance could one of you sent me a > 32-bit /mach_kernel via private email, or else place it on your > website then send me the URL? > > Thanks > > Mike > -- > Michael David Crawford > mdcrawford at gmail dot com > > Custom Software Development for the iPhone and Mac OS X > http://www.dulcineatech.com/custom-software-development/ -- Michael David Crawford mdcrawford at gmail dot com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Lend Me a Kernel?
by Michael Crawford 28 Mar '13

28 Mar '13

Friends, I accidentally deleted my kernel a while back, and have been unable to find a replacement. My problem is that my Mac is a 32-bit machine, which is way out of style. By any chance could one of you sent me a 32-bit /mach_kernel via private email, or else place it on your website then send me the URL? Thanks Mike -- Michael David Crawford mdcrawford at gmail dot com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ld64 and getsectdata(): incorrect behavior on sections
by gnidorah＠p0n4ik.tk 28 Mar '13

28 Mar '13

Sorry, i should really brace myself and pay attention to manuals. > or use the newer routine getsectiondata(), which does return a slid pointer. Thanks, that works. Another (not great) option is to build with '-Wl,-no_pie'. 28.03.2013, в 9:54, Shantonu Sen <ssen(a)apple.com> написал(а): > I'm not sure what connection you're drawing with ld64, but the problem is that getsectdata() is documented to not slide the pointed-to data when the image slides, which is the case in recent OSes, where the main executable are linked PIE for ASLR. > > You should either follow the man page, or use the newer routine getsectiondata(), which does return a slid pointer. > > Shantonu > > On Mar 27, 2013, at 9:32 PM, gnidorah(a)p0n4ik.tk wrote: > >> Dear list, >> >> During stage of porting of an old code which uses linker sets and had been linked by now obsoleted ld from cctools i've found that sets are broken when linked with ld64. >> >> Here is a sample code to reproduce the bug: http://pastebin.com/TCbeYzNA . Now please try to build on the system with ld (if you have such environment) and then build on system with ld64. Compare results. Latest will always fail. >> >> This is the correct behavior: >> Program output >> Number of entries in section: 3 >> Data of first entry: 5 >> >> Section contents >> otool -s __DATA my a.out >> a.out: >> Contents of (__DATA,my) section >> 00003080 00003018 0000301c 00003020 >> >> with following ld version: >> ld -v >> Apple Computer, Inc. version cctools-622.9~2 >> >> And incorrect one using ld64: >> Program output >> Number of entries in section: 3 >> './a.out ' terminated by signal SIGSEGV (Address boundary error) >> >> Section contents >> otool -s __DATA my a.out >> a.out: >> Contents of (__DATA,my) section >> 0000000100001030 24 10 00 00 01 00 00 00 28 10 00 00 01 00 00 00 >> 0000000100001040 2c 10 00 00 01 00 00 00 >> >> ld -v >> @(#)PROGRAM:ld PROJECT:ld64-136 >> configured to support archs: armv6 armv7 armv7s i386 x86_64 >> LTO support using: LLVM version 3.2svn, from Apple Clang 4.2 (build 425.0.27) >> >> Any ideas how to workaround this problem? >> ( Is any build of an old ld for i386 or/and x86_64 uploaded somewhere publicly or otherwise build instructions for it? ) >> >> Thanks much. >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/darwin-kernel/ssen%40apple.com >> >> This email sent to ssen(a)apple.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ld64 and getsectdata(): incorrect behavior on sections
by Shantonu Sen 28 Mar '13

28 Mar '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

ld64 and getsectdata(): incorrect behavior on sections
by gnidorah＠p0n4ik.tk 28 Mar '13

28 Mar '13

Dear list, During stage of porting of an old code which uses linker sets and had been linked by now obsoleted ld from cctools i've found that sets are broken when linked with ld64. Here is a sample code to reproduce the bug: http://pastebin.com/TCbeYzNA . Now please try to build on the system with ld (if you have such environment) and then build on system with ld64. Compare results. Latest will always fail. This is the correct behavior: Program output Number of entries in section: 3 Data of first entry: 5 Section contents otool -s __DATA my a.out a.out: Contents of (__DATA,my) section 00003080 00003018 0000301c 00003020 with following ld version: ld -v Apple Computer, Inc. version cctools-622.9~2 And incorrect one using ld64: Program output Number of entries in section: 3 './a.out ' terminated by signal SIGSEGV (Address boundary error) Section contents otool -s __DATA my a.out a.out: Contents of (__DATA,my) section 0000000100001030 24 10 00 00 01 00 00 00 28 10 00 00 01 00 00 00 0000000100001040 2c 10 00 00 01 00 00 00 ld -v @(#)PROGRAM:ld PROJECT:ld64-136 configured to support archs: armv6 armv7 armv7s i386 x86_64 LTO support using: LLVM version 3.2svn, from Apple Clang 4.2 (build 425.0.27) Any ideas how to workaround this problem? ( Is any build of an old ld for i386 or/and x86_64 uploaded somewhere publicly or otherwise build instructions for it? ) Thanks much. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current working directory (path string) of another process without triggering a getattr() on the inode
by Jakob Blomer 23 Mar '13

23 Mar '13

Hi Paul, Cheers, Jakob On 3/24/13 12:20 AM, Paul Nelson wrote: You might look at the source code for lsof. It lists the current working directories for processes: sudo lsof | grep cwd Paul On Mar 23, 2013, at 6:03 PM, Jakob Blomer <jblomer(a)cern.ch> wrote: Hi, I would like to figure out the current working directories of other running processes. I have been looking at libproc, and proc_pidinfo with PROC_PIDVNODEPATHINFO almost does what I need. The problem is that it not only returns the path string but also a struct stat of the corresponding file system entry. In my use case this approach results in a dead lock. I run the code from inside a fuse file system in order to figure out the current working directories that reside on that very fuse filesystem. In order to avoid a race with newly spawned processes or processes changing their working directory, the fuse module blocks all VFS callbacks prior to enumerating the current working directories. I was also hoping that sysctl with KERN_VNODE might help but this functionally has been removed from newer XNU kernels. Would there be another, block-free way of enumerating the paths of the current working directories? Ideally, I'm looking for something that works like a readlink on /proc/PID/cwd under Linux. Cheers, Jakob _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/nelson%40thursby.com This email sent to nelson(a)thursby.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com as far as I can see, lsof uses PROC_PIDVNODEPATHINFO and hence is also affected by the deadlock.

1 0

Re: Current working directory (path string) of another process without triggering a getattr() on the inode
by Paul Nelson 23 Mar '13

23 Mar '13

You might look at the source code for lsof. It lists the current working directories for processes: sudo lsof | grep cwd Paul On Mar 23, 2013, at 6:03 PM, Jakob Blomer <jblomer(a)cern.ch> wrote: > Hi, > > I would like to figure out the current working directories of other running processes. I have been looking at libproc, and proc_pidinfo with PROC_PIDVNODEPATHINFO almost does what I need. The problem is that it not only returns the path string but also a struct stat of the corresponding file system entry. > > In my use case this approach results in a dead lock. I run the code from inside a fuse file system in order to figure out the current working directories that reside on that very fuse filesystem. In order to avoid a race with newly spawned processes or processes changing their working directory, the fuse module blocks all VFS callbacks prior to enumerating the current working directories. > > I was also hoping that sysctl with KERN_VNODE might help but this functionally has been removed from newer XNU kernels. Would there be another, block-free way of enumerating the paths of the current working directories? Ideally, I'm looking for something that works like a readlink on /proc/PID/cwd under Linux. > > Cheers, > Jakob > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/darwin-kernel/nelson%40thursby.com > > This email sent to nelson(a)thursby.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Current working directory (path string) of another process without triggering a getattr() on the inode
by Jakob Blomer 23 Mar '13

23 Mar '13

Hi, Cheers, Jakob _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com I would like to figure out the current working directories of other running processes. I have been looking at libproc, and proc_pidinfo with PROC_PIDVNODEPATHINFO almost does what I need. The problem is that it not only returns the path string but also a struct stat of the corresponding file system entry. In my use case this approach results in a dead lock. I run the code from inside a fuse file system in order to figure out the current working directories that reside on that very fuse filesystem. In order to avoid a race with newly spawned processes or processes changing their working directory, the fuse module blocks all VFS callbacks prior to enumerating the current working directories. I was also hoping that sysctl with KERN_VNODE might help but this functionally has been removed from newer XNU kernels. Would there be another, block-free way of enumerating the paths of the current working directories? Ideally, I'm looking for something that works like a readlink on /proc/PID/cwd under Linux.

1 0