What happened before the Linux program was executed--the programmer's self-cultivation

is the kernel done with the loading and linking of the program?

Knowing that Linux has fork and exec system calls, can create new processes and execute executable files, fork is the kernel's own data structure maintenance, understandable, then exec specify a file, how to load files and dynamic links?

Interpreter

• The kernel maps to user-space memory when executing elf files
• Looking for special sub-segments in Elf interp
• Kernel mapping interpreter to user space, control over to interpreter
• Interpreter complete load, link, execute user program

Elf interpreteris specified in the Elf executable, and Linux is probably the /lib64/ld-linux-x86-64.so.2 full path of a library, and the kernel gives control to interpreter, an executable memory code. This is not part of the kernel, which is usually provided by GLIBC.

So, 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 contracts a concept of interpreter Such an entry, to the user space Declaration, after calling exec Syscall, loading the executable file into memory, memory mapping, Then the PC (program counter) starts the application from interpreter, and the control is handed over to the user space.
Although an OS has only one interpreter, it is also possible for a third party to develop a single interpreter without using the interpreter provided by GLIBC. Interpreter conventions How the application orchestrates instructions (including whether dynamic linking is supported) Syscall already provides the possibility that MMAP provides the underlying implementation for dynamic linking.

Dynamic Link Library

The address space of each process covers the dynamic-link library, except that the dynamic-link library has only one copy in memory, and the memory map of the kernel reaches the effect that multiple process address spaces can cover.
By /proc/<pid>/maps looking at the mapped file, this mapping differs from loading, which means that the symbol linkingis required.

After kernel completes the elf file to the memory mapping, kernel the dynamic linker also mapping to the program address space. The kernel also mapping other such as BSS, putting parameters and environment on the stack. After determining the start address of the ld.so (or by reading a specific section), set the start address of the process. The starting position of the special section logger in Elf.

ld.so Check all the dynamic link libraries in the Elf file, mapping to memory, but not immediately link, because mapping is fast, and symbolic links are time-consuming.
ldd /bin/lsYou can view the elf's dynamic link library, note that LDD is a tool application, and ld.so is a library that is called interpreter and needs to complete link and load.

Dynamic link library Multiple programs are shared, why does the data not interfere?

There is a function in the library, the function has a local variable, and the function has only one copy, why do multiple programs call the same function, local variables do not cause interference?

Guess: Local variables are allocated on the stack, and each process's stack is independent. Declaring a local variable in a function requires allocating space, which is the space on the stack, and the access to the local variable in the subsequent instruction of the library function is offset by the stack base address, and even a variable name is not saved to the code snippet of the dynamic library. The variable "slot" needs to be prepared on the stack of the process before the library function is called

What happened before the Linux program was executed--the programmer's self-cultivation