link libraries and address-independent codes

"Static connections and dynamic link Libraries"

[static link]---> Static libraries: Link and load the source program to virtual memory
[dynamic link]---> Shared libraries:
<1> Static shared libraries:For each library, the operating system assigns a specific virtual memory address, the module mounts to that particular virtual address, and if the current shared library is not loaded, the address space is idle. That is, the final load address is not determined at compile time, when the link is known the library so determined;
<2> Dynamic Shared libraries:When a dynamic shared library is loaded, the virtual address is dynamically assigned by the loader based on the current virtual memory address space, i.e. the final load address is still not determined at the time of the link until it is loaded.

[noun analysis]
Links:source files and library files to establish links;
Load:The mapping between the linked file establishment and the virtual memory;
Link Relocation:
Refers to a static link, the link before the source file referenced in the library file function name (such as add) address are recorded as 0x0000, link after the classification of the function relative to the link after the file start address 0 relative address (such as 0x1000), from 0x0000--> The change of the 0x1000 address is the link relocation, which only needs to offset the corresponding amount when the link is loaded.
Mount Relocation:
Dynamic link because the link is dynamically loaded library files into virtual memory, the linked file is not a whole and cannot calculate the relative address, so can only be loaded into virtual memory when the current memory address of the library.

"Shared object Structure Analysis"
[. Data] Segment:Automatically store elf file data segments
The global variable data segment (. Data segment) in the shared library is loaded with the executable's data segment (. Got segment), which is a copy of the global variables of its child shared libraries in each process's executable file.
Local variables in the shared library are stored in the code snippet (. Text field) and loaded into the in-memory stack when execution begins

[. interp] Dynamic Link Interpretation segment:Specifies the dynamic linker path.

[. Dynamic] Dynamically linked segments:Store dynamic Link basic information
DT_SYMTAB:[.DYNSYM] dynamic link symbol table address;
Dt_strtab: Dynamic connection string table address;
Dt_rel: Dynamic Link Relocation table address, including Code Snippet relocation table (. rel.text) and data segment relocation (. rel.data).
Dt_need: The shared object file of the current ETF file
... ...
[. symtab] static link symbol table:storing static link symbol tables
--------------------------------------------------------------------------------------------------
Q: Symbol table and static link symbol table relationships in dynamic link segments?
A: The dynamic Link table (. dynsym) stores only dynamic link symbols, while the static link symbol table (. symtab) holds all symbols (including dynamic).
--------------------------------------------------------------------------------------------------
[. Text] Code snippet:Need to do address-independent code conversion!
The code snippet is related to the absolute address:
That is, the code snippet corresponds to this certain virtual address, then it can not be shared by multiple processes, because it is not randomly allocated by the operating system, that is, we have been compiled to know its address, this is the static shared library (obsolete);
When other processes want to use this absolute address, yes! Because this address has long been known.
The code snippet is independent of the absolute address:
That is, the absolute address of the code snippet when loading to get an absolute address, before loading we only know the relative address, the loading process of the operating system in memory space randomly assigned an absolute address (known)!
When other processes want to use this absolute address, the code and data in the current virtual memory are mapped to the address space of the other process.

---------------------------------------------------------------------------------------------------------------
static Link: Re-location when linking;
Static Shared library: no relocation required;
Dynamic Shared library: relocation when loading;
Dynamic Shared libraries:Allocate virtual memory at load time, the first address of each dynamic library must be relocated-shared, but the code snippet of dynamic shared library may produce the code related to address: this time we need-fpic to help us to translate the address code in the code snippet into the address-independent code, There are many easy-to-use code snippets (read-only) and data segments (reading and writing) in shared objects, and if we do not make address-independent code This step, then when the shared library is reused from the virtual memory of one process to another, you can calculate the code inside the shared object, but you have to set aside space. and automatically allocating space is a violation. ---------------------------------------------------------------------------------------------------------------
[Code snippet Independent Code implementation]:
<1> internal:The offset is reserved to calculate the current address, which is independent of the absolute address.
Module internal function call and jump;
Module internal data access.
<2> external:Rely on the address dependency/symbol table to find the absolute address,
Data access between modules,---> The global variable address segment (. Got segment) that is stored in this file, ATT: not an executable file
Inter-module function call/jump;---> Save to this file a function reference address segment (. GOT.PLT segment), ATT: not an executable file
The Att:.got segment contains the symbol and address of the global variable of this file, which is only indexed in the segment using one of the variables.
Three items stored in the ATT:.GOT.PLT segment
<1>.dynamic segment address, use a function name only in the dynamic Link symbol table index can find the referenced address;
<2> Store the ID of this module's link library, as in test.so, is test.
<3> stores the _dll_runtime_resolve () function address, which is used to complete address binding based on address and symbol.


[In short]
To load a shared object:Ensure that the internal code snippet of the shared object required by multiple processes is independent of the absolute address, and that the data/functions related to the absolute address are dynamically linked and stored in the. Dynamic segment of each shared object.

void Main () {
CPU control transfer to dynamic linker;
The operating system tells the dynamic linker basic information about the executable file (including the entry address, the basic information of the segment, etc.);
The dynamic linker uses its own static link to Bootstrap, after which the executable file is statically linked to a specific address in memory;
Then find the shared object file that the current file depends on by looking at the dt_need in the. Dynamic section of the executable file.

while (each mapping of a dependent dynamic object) {
View the dynamic segment of the animated object to see if the object depends on other objects, and if so, return to the previous loop;

Merges the symbol table in the current dynamic object file into the global symbol table in the virtual space;
Mapping global variables and static local variable loads in the current dependent file to a static zone in virtual memory;
The local variables of the executable file and the dependent file are stored in the stack, and the function of the stack is destroyed automatically when the stack is left.
Map the program code to the virtual Memory program code area;
if (all dependent objects are loaded)
Break
/*elf and Linux process virtual space mapping completed */

CPU control transfers The executable file entry address;
executable file execution begins;
Process Virtual Space--Physical space
/* Virtual space and physical space mapping complete */
}

link libraries and address-independent codes