|
Log In | Not a Member? |
Contact ADC
|
The dynamic loader for Darwin/Mac OS X is called dyld, and it is responsible for loading all frameworks, dylibs, and bundles needed by a process.
New Features
Deprecated APIs
Known Issues
Dynamic Library Unloading
In prior versions of Mac OS X only bundles (file type MH_BUNDLE) could be unloaded. In Mac OS X 10.5 dynamic libraries (file type MH_DYLIB) can also be unloaded when using dlopen/dlclose. Dyld uses reference counting to determine when a dylib or bundle can be unloaded. NSBundle and CFBundle now use dlopen/dlclose, so releasing an NSBundle or CFBundle object can unload the code it represents. For compatibility, using a deprecated API such as NSAddImage to load a dylib will mark it so that it can never be unloaded.
RPATH
Traditionally on Mac OS X dependent libraries are specified with an absolute path (e.g. /usr/lib/libSystem.B.dylib). The dyld in Mac OS X 10.5 now supports “run path relative” library paths. There is two parts to using this functionality. The first part is to build a dylib with an install name that starts with @rpath/ (e.g. @rpath/libfoo.dylib). Any clients that link with that dylib with then have run path relative load path to the dylib. The second part is specifying the list of directories that dyld should search to resolve run path relative load paths. This is done with the linker option -rpath dir. The dir path can be an absolute path or start with@loader_path/ and be relative to the executable containing the rpath.
Typical usage is that run path relative framework Foo would have a install name of “@rpath/Foo.framework/Versions/A/Foo”, and a dylib foo would have a run path relative path of “@rpath/libfoo.dylib”. Then the main executable which will need to load these would be linked with one or more -rpath options. If all the run path relative frameworks and dylibs are to be contained within an application .app directory, then the -rpath directories would start with @loader_path.
RTLD_FIRST
This is a new option to dlopen. It specifies that when the returned handle is passed to dlsym only the library specified should be searched for the requested symbol. Without the RTLD_FIRST option, if the specified library does not contain the symbol, dlsym() continues to search other libraries loaded by the specified library.
dlopen_preflight()
This is a new function to test if a library is loadable. It is useful for building a UI element that shows a list of available plug-ins. A library may not be loadable if it is the wrong architecture (e.g. 32-bit plugin but process is 64-bits, or ppc plugin but process is intel), or is garbage-collection incompatible (e.g. gc-unaware plugin in gc enabled process).
setuid binaries
For security, when running a setuid binary, dyld ignores and deletes all DYLD_ environment variables. In addition @executable_path base load paths cannot be used in setuid or setgid process.
Position Independent Executables
A main executable targeting Mac OSX 10.5 can be linked with with -pie option (-Wl,-pie through gcc). That option causes dyld to load the main executable at a random address. This can help defend against a certain class of attacks that exploit jumping to known locations. This option can only be used if all code in the main executable was compiled without -mdynamic-no-pic which means there is a small performance penalty for building PIE.
dyld shared cache
Mac OS X 10.5 no longer uses prebinding for the OS itself. Instead a “cache” file is built from commonly used dylibs. The cache is automatically rebuilt whenever one of the dylibs in the cache is updated (usually just during a Software Update). When the cache is built, the addresses of the dylibs are intentionally randomized, thus when debugging you may notice that the address of OS routines like malloc is different on every machine.
Most APIs in <mach-o/loader.h> have been deprecated in Mac OS X 10.5. The cross-platform APIs in <dlfcn.h> are the preferred replacements.
weak symbols are too expensive
C++ uses weak symbols to tell ld and dyld to coalesce. Any weak external symbols in a linkage unit will cause dyld to do extra work to assure there is only one copy of that symbol in the process. The current implementation uses an O(n^2) algorithm.
No fast thread local storage
pthread_getspecific() is currently the only option
No dl* way to load memory based mach-o images
NSCreateObjectFileFromMemory is deprecated. Some programs decrypt or synthesize mach-o files in-memory. There should be a dl* based API which can use a mach-o file that exists only in memory and not on disk.
Spurious “(com.apple.dyld): Throttling respawn:“ messages in Console
If you alter or replace an OS dylib that participates in the dyld shared cache, dyld will continually try to update the shared cache. But the rebuilt shared cache will not take effect until you reboot. Until the reboot, launchd may throttle (pause) update_dyld_shared_cache.
MH_BINDATLOAD ignored
At build time the linker option -bind_at_load sets the MH_BINDATLOAD bit in the mach_header flags. But at runtime dyld does not check for the MH_BINDATLOAD bit. In Mac OS X 10.3 and earlier, this flag was usually used as a work around to run initializers correctly, and that is no longer necessary in Mac OS X 10.4 and later.
Last updated: 2007-10-31
 |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |