RE: 10.4, MH_BUNDLE, and DYLD_IMAGE_ADDED dyld_events
RE: 10.4, MH_BUNDLE, and DYLD_IMAGE_ADDED dyld_events
- Subject: RE: 10.4, MH_BUNDLE, and DYLD_IMAGE_ADDED dyld_events
- From: "Nathan Herring" <email@hidden>
- Date: Thu, 24 Nov 2005 07:59:49 -0800
- 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:email@hidden]
Sent: Wednesday, November 23, 2005 11:08 PM
To: Nathan Herring
Cc: email@hidden
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden