site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: AcXwxnM2IbldLdN2SIWx8k1pb/3U9gAR8Zjw Thread-topic: 10.4, MH_BUNDLE, and DYLD_IMAGE_ADDED dyld_events Hmm. There's a comment in the top of http://darwinsource.opendarwin.org/10.4.3/dyld-44.2/src/dyld_debug.c: // The following API's are deprecated. // In Mac OS X 10.4 we only do a minimal implementation of these API's // to keep from breaking existing clients (Omni and MS Crash Reporters). // // This minmal implementation only allows inspection of one process and // only reveals the current images in that process (no notification of // later image changes). It assumes both processes use the same dyld // and dyld has not slid in either process. Well, it cannot assume that dyld has not slid, because it always slides bundles. Unfortunately for us, in Office 2004, we're largely CFM, and our only Mach-O code is in, yes, you guessed it, a MH_BUNDLE. Our crash reporter generates these broken logs in 10.4, and if the crash was in our Mach-O code, we have no idea where it was, and they all get bucketed identically in the "unknown" bucket. Thanks for the information. It appears that you (Omni) and I (MS) are the consumers of this deprecated API. -nh -----Original Message----- From: Timothy Wood [mailto:khavi@mac.com] Sent: Wednesday, November 23, 2005 11:08 PM To: Nathan Herring Cc: darwin-dev@lists.apple.com Subject: Re: 10.4, MH_BUNDLE, and DYLD_IMAGE_ADDED dyld_events On Nov 23, 2005, at 9:14 PM, Nathan Herring wrote:
For MH_DYLD libraries, vmaddr is set to the base address and vmaddr_slide is set to 0. For MH_BUNDLE libraries (under 10.3 and earlier), vmaddr is 0, and vmaddr_slide is set to the base address. However, in 10.4, vmaddr_slide is set to 0, and we don't have any idea where the bundle is living in memory.
We're acquiring this information by calling _dyld_debug_subscribe_to_events and handling DYLD_IMAGE_ADDED events, looking in arg[0].vmaddr_slide. This does not seem to be working any longer.
You might be running into Radar 4149320: dyld_debug API shim computes incorrect slide. Note that in 10.4 dyld was massively rewritten. As part of this, the dyld_debug API was deprecated and the shim was added. The way things work now is that dyld has some global state (search for "dyld_all_image_infos" in the dyld source) for listing the loaded modules and notifies listeners by calling a empty function ("notification" element of the aforementioned global). The listeners are expected to have set a breakpoint on this function; it isn't clear to me how to get multiple listeners to work since I've never gotten forwarding of Mach exceptions working right. If you are running in the same process, you can probably just access the globals, though we take the approach of not trusting the process at this point (since, hey, it crashed) and we fork another process to collect the crash. This has its own set of compatibility issues (see the mysterious setgid flag on the real gdb executable in Xcode 2.2 and higher...) At any rate, here is the text of my Radar: ----- In dyld-43, dyld_debug.c, the function slideForHeader is busted. In particular, this breaks for any file that did get slid (MH_BUNDLE or MH_DYLIB most frequently). The two errors that I've spotted so far are: 1) const struct segment_command *sgp = (const struct segment_command *)((char*)mh + sizeof(mh)); This should have "sizeof(*mh)". Otherwise "sgp" starts out 4 bytes into the struct mach_header instead of after it. Obviously this causes badness, but it is hidden in my cases since the cmdsize computed from this bogus pointer is zero (so the 'for' loop doesn't wander off and crash noisily). 2) return (uintptr_t)mh - (uintptr_t)sgp->vmaddr; This is using "mh", a local pointer obtained from malloc (i.e., meaningless garbage), instead of "otherAddressHeader", the target task's pointer. In my 10.4-ification of our OmniMachO framework (used in OmniObjectMeter and OmniCrashCatcher), I've copied over something like this function and fixed it up and I'm starting to get correct slide values. ----- This Radar is still marked 'Open', so apparently it didn't make it into 10.4.3. Note that even though I was able to produce a version of the shim function that worked, we don't use this approach any more when running on 10.4 (we look for the dyld_all_image_infos symbol in / usr/lib/dyld and if so, we use the global table). I hope this helps! -- Timothy J. Wood The Omni Group _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com