|WikiProject Computing / Software / Security||(Rated Start-class, Mid-importance)|
I have found that the article is missing large sections of information and contained a decent amount of disinformation. I have rewritten the article, if you believe the previous article is more accurate please merge that article with this one to produce a mixed article since the previous one had many errors in it and was light on details. While don't believe this new article is perfect I do believe it is an improvement. CupOfJava (talk) 11:51, 3 December 2009 (UTC)
Linux doesn't use .interp?
The article says
- The GNU/Linux based operating systems implement a dynamic linker model where a portion of the executable includes a very simple linker stub which causes the operating system to load an external library into memory. This linker stub is added at compile time for the target executable. The linker stub's purpose is to load the real dynamic linker machine code into memory and start the dynamic linker process by executing that newly loaded dynamic linker machine code. While the design of the operating system is to have the executable load the dynamic linker before the target executable's main function is started it however is implemented differently. The operating system knows the location of the dynamic linker and in turn loads that in memory during the process creation. Once the executable is loaded into memory the dynamic linker is already there and linker stub simply executes that code. The reason for this change is due to the fact that ELF binary format was designed for multiple Unix-like operating systems and not just the GNU/Linux operating system.
That sounds more like a description of the SunOS 4.x operating system's dynamic linker model, where the C startup code mapped ld.so into memory and ran it, rather than the dynamic linker model used in, for example, SunOS 5.x, where the .interp section of the ELF executable has the pathname of an "interpreter" for the executable, and, for dynamically-linked executables, that "interpreter" is the run-time linker. (That was done so that the executable image would not have to contain any system call traps - not even the ones that the SunOS 4.x C startup code used to open the run-time linker and map it into the address space - and therefore would not, in any way, depend on the binary interfaces for any system call traps being stable.) Does Linux really do that differently? Does "The reason for this change is due to the fact that ELF binary format was designed for multiple Unix-like operating systems and not just the GNU/Linux operating system." mean that this was done to support running non-Linux ELF binaries on Linux systems? Guy Harris (talk) 23:51, 20 June 2010 (UTC)
Source of Mac OS X
"While the source code to Apple's Mac OS X dynamic linker is not available, an similar open source version is. The open source version of the Apple Mac OS X platform is often simply called Darwin. While at one time the source code for both were the same, with small sections of the code omitted by Apple, the source code today has diverged and the two are actually very different, with patches and changes kept in sync between the two different source code trees (SourceCaches). The open source version of dynamic linker (dyld) can be found at Apple's open source web site "
I think it is not clean, where is any links to the differences between code in the Mac OS X and in the Darwin? One is just open source of the part of the Mac OS X. —Preceding unsigned comment added by 220.127.116.11 (talk) 08:53, 21 September 2010 (UTC)
- The claim that Mac OS X uses code different from the Darwin code is false. Guy Harris (talk) 10:01, 12 March 2012 (UTC)
I think the explanation of linker execution used throughout this page is somewhat inaccurate, particularly the tidbit saying that a new process is created for the linker. I know in Linux, at least, that this is not true. While the linker (ld.so) is, indeed, another executable, I'm certain that the kernel doesn't create a new process for it. Instead, it maps the the linker into the new process's address space and jumps to it. Aikigaeshi (talk) 23:03, 11 March 2012 (UTC)
- I don't think they intended to say that a process is created for the dynamic linker separate from the process that's running the dynamically-linked executable image. If you're referring to "In most Unix-like systems that use ELF for executable images and dynamic libraries, most of the machine code that makes up the dynamic linker is actually an external executable that the operating system kernel loads and executes first in a newly constructed process address space.", I think "newly constructed" refers to the address space, not the process - if an already-existing process does an exec call that starts a dynamically-linked executable, the exec call clears out the old address space and constructs a new address space, and then loads the run-time linker, not the executable image, into the address space and transfers control to it. It passes to the run-time linker a file descriptor that refers to the executable image; the run-time linker then maps the executable image into the address space and does the linking, mapping shared libraries into the address space as well. When it's done, it transfers control to the executable image's start code. (With a call such as posix_spawn(), a new process is, of course, created and launched with the run-time linker, but that process ends up running the executable image, so, again, the run-time linker and executable image run in the same process.)
- (This was done in order to avoid the executable image's startup code having to make any system calls to load the run-time loader into the address space; the SunOS 4.x shared library mechanism, from which the SVR4 mechanism was derived, started the run-time linker that way, but that meant that, to preserve binary compatibility, the system call trap interface for those system calls couldn't be changed in a binary-incompatible fashion. In a system where the run-time linker is what's loaded by the exec call, the system ABI can be defined entirely in terms of procedure calls to routines in dynamically-linked libraries, with no need to expose the system call trap interface as part of the ABI; that was one of the goals of the SVR4 shared library mechanism, as I remember from when I was at Sun during the early days of the SVR4 work.) Guy Harris (talk) 00:56, 12 March 2012 (UTC)