Some records about static links, dynamic links, shared libraries, and ABI (OS learning)

Static Linking
If you find the reference in the obj file during ld, the binary code of this reference will be added to your program in libary.
The static link program is a truly complete and runable program. You only need the OS kernel to call this code when running the program.
In static links, the most important thing is to add the binary program in libary to the program that calls the library function.

Dynamic Linking
During dynamic link, if the code we write calls the code in the library, the binary code in the library will not be directly added to our code here, but the reference will be retained, during program loading and running, note that during code running, the reference retained in the program will be linked to libary for execution by the linked program. The advantage of dynamic link is that the on disk program can be very small, saving memory. The result of dynamic link is (shared libray ), the dynamic link program depends on the libary containing the reference. If the OS does not contain the reference library file, the program we write will not be able to run.

Shared Libraries
Shared Library
Package many files that can be run independently into libary, which means that we do not need to add binary files in libary to the executable file, and adjust the reference in executable during runtime, in this way, all execuable programs can find libary binary in same memory.
This requires some tips. The binary program in libary cannot have any static variables or global variables. If there are static variables or global variables, this binary program provides a separate variable space for each program that calls it. This technique is usually used in multi-threaded programs. A program may have multiple control flows.

The location of the library file in virtual memory may not be certain, that is, the location of the library file may change frequently, which requires that the dynamic library file can be run at any location, the generated code is irrelevant to the running position. (Such code can be obtained by adding the position independent code option during GCC compilation ). This location-independent code requires the support of the elf File Format. The efficiency of location-independent code may be lower (this is the cost)

ABI-Application Binary Interface
Standard for calls in applications and binary programs:
ABI defines how libary functions are called and how syscall is called. This call standard includes: the parameter is stored in the stack or in register, where is the function entry point in libary, and other content.
When static linkage is used, the generated executable program is the same as the ABI standard used by kenel to call the application.
When dynamic linkage is used, the generated programs must be consistent with the ABI standard used in libary.

Unresolved Symbols
Unresolved symbols (that is, the reference in the program when dynamic linkage is used, or the symbol cannot be found when static linkage is used)

Linker will run some reference that you don't know.
For example, ($ (V) $ (LD)-o $ @ $ (KERN_LDFLAGS) $ (KERN_OBJFILES) $ (GCC_LIB)-B binary $ (KERN_BINFILES ))
These references include alloca (), memset (), memcpy (), and other functions (in libgcc. ).
We often fail to compile our OS kernel because we do not normally use tool chain or command line configuration. Or some of the functions we call are not implemented in libary. When we do not use the library file libgcc (including memcpy memmove, memset, and memcmp) during ld, an error occurs.

Other symbols, such as Division, _ udiv, and remainder _ umode. It can also be found in the libgcc library file. If you missing such symbols during ld, remember to link with libgcc during ld.