If the dynamic linker/loader is itself a shared object file, how is it properly loaded into a dynamically linked program's process image space if it's not already there? Is this some kind of catch 22 thing?
Asked
Active
Viewed 1,056 times
1
-
See [When/How does Linux load shared libraries into address space?](https://stackoverflow.com/questions/5130654/) – Jonathan Leffler May 28 '17 at 06:39
-
From your link, the poster said "Libraries are loaded by ld.so", however, my question is how is ld.so loaded in the first place if itself is a "library" (shared object file)... – May 28 '17 at 06:49
-
1And the part that discusses _'It is declared as "interpreter" (INTERP; .interp section) of all dynamic linked ELF binaries. So, when you start program, Linux will start an ld.so (load into memory and jump to its entry point), then ld.so will load your program into memory, prepare it and then run it. You can also start dynamic program with `/lib/ld-linux.so.2 ./your_program your_prog_params`'_ explains that the kernel loads it and runs it and it then interprets the binary, thus avoiding the Catch-22 because the kernel does handle the loading of the dynamic loader. Note I didn't wield Mjölnir! – Jonathan Leffler May 28 '17 at 06:52
-
"Linux will start an ld.so (load into memory and jump to its entry point)", "explains that the kernel loads it and runs it" So if I understand you correctly, the kernel has the ability to perform all of the functionality provided by ld.so such as relocation, etc? – May 28 '17 at 06:56
-
1@John41_, no, kernel have no support of doing ELF relocations in user-space programs. It may only start statically linked ELFs or start some specially written binaries like ld-linux.so which are special (don't require relocations too early, do the relocation processing itself). And interpreted binaries are loaded by the kernel, but processed by ld-linux.so. – osgx May 28 '17 at 16:16
2 Answers
4
This answer provides some details (although there are technical mistakes in it).
Is this some kind of catch 22 thing?
Yes: ld.so is special -- it is a self-relocating binary.
It starts by carefully executing code that doesn't require any relocations. That code relocates ld.so itself. After this self-relocation / bootstrap process is done, ld.so continues just as a regular shared library.
Employed Russian
- 199,314
- 34
- 295
- 362
-
Employed, Can you correct some mistakes by editing the linked answer or answering a technically correct one? – osgx May 28 '17 at 16:13
2
Refer to Oracle Solaris 11.1 Linkers and Libraries Guide It's the best linkers reference that I have come across, concise and explains things well.
On page 89:
As part of the initialization and execution of a dynamic executable, an interpreter is called to complete the binding of the application to its dependencies. In the Oracle Solaris OS, this interpreter is referred to as the runtime linker.
During the link-editing of a dynamic executable, a special .interp section, together with an associated program header, are created. This section contains a path name specifying the program's interpreter. The default name supplied by the link-editor is the name of the runtime linker: /usr/lib/ld.so.1 for a 32–bit executable and /usr/lib/64/ld.so.1 for a 64–bit executable.
Note – ld.so.1 is a special case of a shared object. Here, a version number of 1 is used. However, later Oracle Solaris OS releases might provide higher version numbers.
During the process of executing a dynamic object, the kernel loads the file and reads the program header information. See “Program Header” on page 371. From this information, the kernel locates the name of the required interpreter. The kernel loads, and transfers control to this interpreter, passing sufficient information to enable the interpreter to continue executing the application.
