On Jan 29, 2010, at 7:58 AM, Richard Penwell wrote:
> I've been toying around with some problems in the world of dynamic code
> loading... (a vast and mythical place). I understand that there is a
> fundamental difference between Mach-O executables and Mach-O dynamic
> libraries (beyond the obvious Mach-O filetype header). I assume it has to do
> with a concept I've read about known as Position Independent Code, in that
> Dynamic Libraries are PIC and executables (assuming that they are the first
> object to load and therefore could not have to content for a VM address
> range) are not. The question goes something like this:
>
> Given I have a Mach-O executable file that contains a symbol that I wish to
> be able to call is there any way to use dlopen or NSBundle load to bring
> those symbols into another executable?
>
> I have attempted the following two methods:
>
> NSBundle *applicationBundle = [[NSBundle alloc]
> initWithFile:@"path/to/mach-o/executable"];
> [applicationBundle load]
>
> The above results in:
> 2010-01-29 10:07:41.812 LoadPagesDynamically[93324:a0f] Attempt to load
> executable of a type that cannot be dynamically loaded for CFBundle
> 0x1001161b0 <path/to/mach-o/executable> (executable, not loaded)
>
> Also:
>
> void* pages_application = dlopen("path/to/mach-o/executable", RTLD_NOW);
>
> The above results in pages_application == NULL with no errors being reported.
>
> If it is not possible (I suspect not), is it possible to convert executable
> object code to a PIC representation to be dynamically loaded?
>
> I imagine that there may be something that I don't know given Apple's history
> of binary magic (fat binaries, rosetta etc).
>
> It seems that this is a dark corner of the DYLD system that isn't well
> documented as to the technical aspects of why this isn't done.
>
> I've tried to be as detailed as possible, but if you would like more
> information as to what I've tried, please let me know.
As mentioned earlier, you'll get better answers from darwin-...@lists.apple.com.
You cannot convert a non-PIC binary to PIC. The compiler and linker will have
made optimizations to the non-PIC binary that you can't undo without rebuilding
it from scratch.
A typical main executable is also missing the symbol tables that would be
needed for other code to link to its symbols.
In theory, you could build a PIC-capable symbol-rich main executable. Then
there's no technical restriction against loading it into another process, other
than that dyld isn't designed to do that and most executables wouldn't be
usable that way anyway.
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
