site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Terry, On Jan 7, 2009, at 3:33 AM, Terry Lambert wrote: You will be better off invoking the linker. -- Terry _______________________________________________ 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... On Jan 7, 2009, at 1:24 AM, Joel Reymont <joelr1@gmail.com> wrote: You have to use at least *a* linker; if you don't, you won't be able to import the system call stubs from libc/libsystem I hope to prove you wrong, shortly. This is a Forth so all I need is stubs for dlopen, dlclose, dlsym and dlerror. I also need to jump to an entry point. This works fine on Linux with the ELF format. I don't know how soon it will be, even with the broad strokes I'm about to outline to illustrate the complexity and fragility over updates of what you are attempting. I'm not sure if Linux uses the SVR4 trick of starting the first page of a process at a large virtual offset and always mapping ld.so into the low memory hole starting a 4k or not. I do know that there is a load command in Mach-o that causes dyld (the moral equivalent of ELF ld.so) to be loaded, and that the linker relocates things so that the default thread state struct program counter vale in another load command points to the start address of the dyld start routine, NOT the entry point for your compiled program. After that, after the segment loads (which just establish mappings), the kernel ignores all of the other load commands besides the unix thread state structure, and dyld does the rest based on the other sections. The dlopen et. al. bindings are things that know how to refernce into the dyld (unlike in Linux ELF, where they are static stubs in crt1 that are built with apriori knowledge of where ld.so gets loaded, dyld is permitted to "slide" if necessary, and do does not maintain a nrcessarily fixed location). There is no ELF-like hierarchical linking library against library to ensure visibility of pre-linked code symbols via dlsym. While you may be able to do this on the basis of bundle-style operations, rather than dlopen, you are likely not going to be happy with the results due to the dependence on a non-flat namespace. I also rather expect you aren't going to get help from the tools folks to deal with these issues, or to document how to generate a valid Mach- o. Completely apart from any correctness considerations, we don't promise we won't change all the implementation details at some point in the future, and documenting how things currently work at the level of detail you'd need would likely set certain details in stone which we'd rather not have be that static. And that's all without dealing with the vtable offsets and library preinitialized data and constructors/destructors, or the other necessary symbol relocation (even assuming you are writing PIC-only instructions and using the slightly-different-than-Linux calling conventions). This email sent to site_archiver@lists.apple.com