site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 11:30 +0200 10/9/04, Markus Hitter wrote: But where comes dyld into this play? Is the binary communicating directly with dyld? "nm ls" shows up some entries named "dyld_...". ELF binaries should have the appropriate functions for the elf linker, then. The operation of dyld is something that I've studied in some detail over the past few years. Here's how things work from the kernel perspective. When you exec a binary, the execve (xnu/bsd/kern/kern_exec.c) routine runs. This code reads the first 512 bytes of the executable (look for the "exdata" union). If the executable starts with Mach-O magic, it treats it as a Mach-O file. Otherwise it treats it as a script, finds the shell, and executes that. I won't go into details on this path because you asked about dyld. The next key step is when execve calls load_machfile (xnu/bsd/kern/mach_loader.c). This is the code that's responsible for parsing the Mach-O file and loading it into memory. You'll see that the bulk of the work is done in parse_machfile (same file). This contains some fabulously convoluted logic, but suffice to say that it looks through all of the Mach-O "load commands" and acts on them. One special load command is LC_LOAD_DYLINKER. This command contains the full path to the dynamic linker used to link this program. That eventually triggers a call to load_dylinker to load the dynamic linker's code into the address space (resulting in a recursive call to parse_machfile, yetch!). The return path of this code sets result->dynlinker to true, indicating that a dynamic linker is being used, and sets result->entry_point to the entry point of the dynamic linker rather than the original entry point of the executable. The upshot of this is that dyld is mapped into the process's address space and is the first code that's run. Back in execve you'll see a special case for load_result.dynlinker which causes the kernel to pass an extra parameter to the program if it's using the dynamic linker. This extra parameter, a pointer to the original program's mach_header, allows dyld to do its magic. This email sent to site_archiver@lists.apple.com