Is the loading and linking of programs done by the kernel?
Knowing that Linux has fork and exec system calls, you can create new processes and execute executable files. Fork is the maintenance of the kernel's own data structure. It is understandable, then after exec specifies a file, how to load the file and dynamically link it?
interpreter
- When the kernel executes the ELF file, it maps to user space memory
- Find special subsection INTERP in ELF
- The kernel maps the interpreter to user space and transfers control to the interpreter
- The interpreter completes the load, link, and executes the user program
The ELF interpreter will be specified in the ELF executable file. On Linux, it may be /lib64/ld-linux-x86-64.so.2the full path of a library, and the kernel will give control to Interpreter, an executable piece of memory code. This is not part of the kernel, usually provided by glibc.
Therefore, it is necessary to emphasize that Linux is only the kernel, and the user space is the operating system, starting from the glibc layer. In theory, the kernel just agrees on the concept of an entry such as Interpreter , declare to user space, after calling exec syscall, load executable file into memory, memory mapping, and then PC (program counter) starts the application from Interpreter, and control is handed over to user space.
Although an OS has only one interpreter, it is also possible for a third party to develop a separate interpreter without using the interpreter provided by glibc. The interpreter agrees how the application arranges instructions (including whether to support dynamic linking and other features). syscall has provided mmap with the possibility of providing the underlying implementation for dynamic linking.
dynamic link library
The address space of each process covers the dynamic link library, but there is only one copy of the dynamic link library in the memory, and the effect that the address space of multiple processes can be covered is achieved through the memory mapping of the kernel.
By /proc/<pid>/mapslooking at the mapping file, this mapping is different from loading , which means symbol linking is required .
After the kernel completes the mapping of the ELF file to the memory, the kernel also maps the dynamic linker to the program address space. The kernel also maps others such as bss, and pushes parameters and environments onto the stack. After determining the start address of ld.so (or by reading a specific section), set the start address of the process. A special section in ELF records the starting position of the program.
ld.so checks all the dynamic link libraries in the ELF file and maps them to the memory, but does not link immediately, because the mapping is fast, and the symbolic link is time-consuming, and it is only linked when it takes time.
ldd /bin/lsYou can view the dynamic link library of ELF. Note that ldd is a tool application, and ld.so is a program library, the so-called interpreter, which needs to complete link and load.
The dynamic link library is shared by multiple programs, why does the data not interfere?
There are functions in the library, and the functions have local variables, but there is only one copy of the function. Why do multiple programs call the same function, but the local variables will not interfere?
Guess: local variables are allocated on the stack, and the stack of each process is independent. Declaring a local variable in a function needs to allocate space. This space is the space on the stack. The access to the local variable in the subsequent instructions of the library function is through the stack base address offset, and even a variable name will not be saved to the dynamic library. code snippet. Before the library function is called, the variable "slot" needs to be prepared on the stack of the process