January 2007 - Darwin-dev - lists.apple.com

Re: Thread and Clock related functions load error in NKE module
by Andrew Gallatin 30 Jan '07

30 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Anees Alappat writes: > thread_call_allocate > thread_call_free > thread_call_cancel > clock_get_system_microtime > clock_interval_to_absolutetime_interval > These functions are declared in kern/thread_call.h file. > After sucessful compilation in Xcode , When i tried to load the NKE, i am > getting load error as "Undefined symbols" I think most of these are exported by the Mach system plugin. You can find this for yourself by running nm on the mach-o files underneath /System/Library/Extensions/System.kext/PlugIns/*.kext or by grepping the source in xnu-792.13.8/config/*.exports Try adding this to your Info.plist's OSBundleLibraries dict: <key>com.apple.kpi.mach</key> <string>8.0.0</string> 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… This email sent to site_archiver(a)lists.apple.com

1 0

Thread and Clock related functions load error in NKE module
by Anees Alappat 30 Jan '07

30 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=nXLsxAmUbaAqtDaE7K5MpAb89EFQFIvWl+5z6nAAkpVMKT6qsx9MC8oFwEEPFayGEjtarUaTC9DP03o0E+jC/hstXqHESkUOB2Yv/XK0TNt+w+Ghm/yYvOb7uliZPofJpCzFxux+yHLst58AurcP+NB6Zaip9G8aSWUazxJMl3Q= _______________________________________________ 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: Filesystems and mounting by URL
by Avi Drissman 28 Jan '07

28 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.9 (Macintosh/20061207) it would appear that the necessary API needed for using URLs to refer to filesystems is a private. This means that if I wish to use sshfs I need to use the command-line. - is there any reason why this functionality is not made part of filesystems, instead of being registered in a separate folder? Avi -- Avi Drissman avi(a)drissman.com +--------------------------------------------------------------------+ http://avi.drissman.com/ Argh! My mail server is trunca _______________________________________________ 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 1/28/07 2:41 PM, Andre-John Mas wrote: What the documentation on that site means is that integrating with the Connect to Server dialog in the Finder is not possible without nasty hackery, because the format of a URLMount plugin isn't public (http://developer.apple.com/qa/qa2004/qa1387.html) Not necessarily, you can write an sshfs GUI wrapper. (Or just download the one I made from that site; we released the source code the other day.) Because the concept of a filesystem and the concept of connecting via a URL to a server are related but separate concepts. smime.p7s

1 0

Filesystems and mounting by URL
by Andre-John Mas 28 Jan '07

28 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, I recently downloaded http://code.google.com/p/macfuse/ and reading the documentation it would appear that the necessary API needed for using URLs to refer to filesystems is a private. This means that if I wish to use sshfs I need to use the command-line. I few questsions: - are there any plans to make the necessary API public? - is there any reason why this functionality is not made part of filesystems, instead of being registered in a separate folder? Should I open a bug for this? Andre _______________________________________________ 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: mach in signal handler
by Amanda Walker 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Amanda Walker _______________________________________________ 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 Jan 26, 2007, at 5:13 PM, Steve Checkoway wrote: Steve West wrote: http://smartcrashreports.com/ One, that only works for 10.4. Two, it only works if the user has it installed. Three, we already have working code for this for PowerPC OS X 10.2.8 and above, x86 Linux, and Windows. Four, it still sends the reports to Apple as well--perhaps I don't want Apple to get crash reports for applications that have not yet been released... This email sent to site_archiver(a)lists.apple.com

1 0

Re: mach in signal handler
by Steve Checkoway 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.9 (X11/20061206) Steve West wrote: -- Steve Checkoway _______________________________________________ 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… http://smartcrashreports.com/ One, that only works for 10.4. Two, it only works if the user has it installed. Three, we already have working code for this for PowerPC OS X 10.2.8 and above, x86 Linux, and Windows. This email sent to site_archiver(a)lists.apple.com

1 0

Re: mach in signal handler
by Steve West 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcdBlOz4K4ODCK2IEduVfwAKldLBkg== Thread-topic: mach in signal handler User-agent: Microsoft-Entourage/11.3.3.061214 >> Why write code at all then? What's wrong with Apple's CrashReporter >> facility? :-) > > It's great if you're Apple. Some of us like having crash reports for > our apps sent to us rather than to Cupertino. No offense, mind you :-). http://smartcrashreports.com/ 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

1 0

Re: mach in signal handler
by Amanda Walker 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Amanda Walker _______________________________________________ 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 Jan 26, 2007, at 9:29 AM, Dave Zarzycki wrote: Why write code at all then? What's wrong with Apple's CrashReporter facility? :-) It's great if you're Apple. Some of us like having crash reports for our apps sent to us rather than to Cupertino. No offense, mind you :-). This email sent to site_archiver(a)lists.apple.com

1 0

Re: mach in signal handler
by Steve Checkoway 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 26, 2007, at 6:29 AM, Dave Zarzycki wrote: -- Steve Checkoway _______________________________________________ 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 Jan 25, 2007, at 7:25 PM, Steve Checkoway wrote: If it matters, I would only be calling it from within the signal handler which I don't allow to be reentrant. (If another signal happens while I'm in the handler, I give up and just die.) Well, one of our library calls might be in the middle of a Mach based API. :-( I was afraid that might be the case. If that were the case, what would actually happen? Would the later invocation stomp on the suspended one (which would be fine because the app will be killed before the signal handler exits) or is there some shared state that would be in an inconsistent state or would it block waiting for the other code to leave the handler? I am already suspending all other threads using mach apis and that seems to work. At least, I have yet to have a problem with it. I have zero preferences on which api to use to get the job done, so if you can suggest a more suitable one, I'd be more than happy to use it. Why write code at all then? What's wrong with Apple's CrashReporter facility? :-) Two things. One, it hasn't been triggered by that point and two, there're no programatic hooks I know of. smime.p7s

1 0

Re: mach in signal handler
by Dave Zarzycki 26 Jan '07

26 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 25, 2007, at 7:25 PM, Steve Checkoway wrote: davez _______________________________________________ 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… Dave Zarzycki wrote: I don't remember if Mach based APIs are interruptible by signals, but if they are, then the answer is definitely no. Why? The reply port can get out of synchronization do to the unexpected reentrancy on the same thread stack. If it matters, I would only be calling it from within the signal handler which I don't allow to be reentrant. (If another signal happens while I'm in the handler, I give up and just die.) Well, one of our library calls might be in the middle of a Mach based API. :-( Personally speaking, I try and handle as many signals as I can via the kqueue API. The only signals that can't be handled in a kqueue are instruction stream or memory access related faults (SIGBUS, SIGSEGV, SIGILL, and SIGFPE). If the aforementioned signals are what you are trying to handle, I'd suggest setting up a dedicated thread to handle signals (man sigsuspend). All other threads should have their signal mask setup to block delivery. What I'm actually doing is attempting to get a back trace on x86 under crash conditions. It's fairly easy on ppc. For x86, I'd like to walk along the stack looking for what might be return addresses, presumably they'd be in executable, readable, but not writable memory and would be proceeded by one of the call instructions. If the code hasn't been compiled with -fomit-frame-pointer, then I'd also like to be able to find valid stack frames by checking that the stored %esp actually points up the stack. I was hoping that vm_region would let me both check what the valid range of memory for a thread's stack and also check if values on the stack point to potential call sites (well, right after the call site) including the protection. I have zero preferences on which api to use to get the job done, so if you can suggest a more suitable one, I'd be more than happy to use it. Why write code at all then? What's wrong with Apple's CrashReporter facility? :-) This email sent to site_archiver(a)lists.apple.com

1 0