Link Library and address irrelevant code, Link Library address

Link Library and address irrelevant code, Link Library address

[Static connection and dynamic link library]

[Static link]---> Static library: Link to the source program and load it to the virtual memory
[Dynamic Link]---> Shared Library:
<1> static Shared Library:For each database, the operating system allocates a specific virtual memory address. The module loads the address to this specific virtual address. If the current shared library is not loaded, the address space is idle. That is, the final loading address is not determined during compilation, and the link is determined because the library is known;
<2> dynamic Shared Library:During dynamic shared library loading, the loader dynamically allocates virtual addresses based on the address space in the current virtual memory. That is, the final loading address remains unconfirmed at the link until it is loaded.

[Glossary]
Link:Establish a link between the source file and the library file;
Load:Mappings between linked files and virtual memory;
Link relocation:
When a static link is used, the function names (such as add) of the library files referenced in the source file before the link are recorded as 0x0000, after the link is sorted, the relative address (for example, 0x1000) of the function relative to the start address 0 of the file after the link is obtained. The conversion from 0x0000 --> 0x1000 address is the link relocation; after the link is loaded, you only need to offset the corresponding amount at the same time.
Load relocation:
The dynamic link is used to dynamically load the library file to the virtual memory. The linked file is not a whole and cannot calculate the relative address, therefore, the current memory address of the database can be obtained only when it is loaded to the virtual memory.

[Shared object structure analysis]
[. Data] data segment:Automatically saves ELF file data segments
The global variable data segment (. data Segment) is incorporated into the data segment of the executable file during loading (. got segment), that is, a copy of the global variable of its sub-shared library exists in the executable file of each process.
Local variables in the shared library are stored in the code segment (. text Segment). After execution, the local variables are loaded into the memory stack.

[. Interp] Description section of the dynamic link:Specifies the path of the dynamic linker.

[. Dynamic] dynamic link segment:Stores basic information about dynamic links.
DT_SYMTAB: [. dynsym] dynamic link symbol table address;
DT_STRTAB: the address of the dynamically connected string table;
DT_REL: the address of the Dynamic Link relocation table, including the code segment 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:Static link symbol table
Bytes --------------------------------------------------------------------------------------------------
Q: What is the relationship between the symbol table and the static link symbol table in the dynamic link segment?
A: The Dynamic Link Table (. dynsym) only stores dynamic link symbols, while the static link symbol table (. symtab) stores all symbols (including dynamic ).
Bytes --------------------------------------------------------------------------------------------------
[. Text] code segment:Address-independent code conversion is required!
The code segment is related to the absolute address:
That is, the code segment corresponds to a specific virtual address, so it cannot be shared by multiple processes because it is not randomly allocated by the operating system, that is to say, we have known its address after compilation, and this is the static shared library (which has been eliminated );
If other processes want to use this absolute address, you can! This address has long been known.
The code segment has nothing to do with the absolute address:
That is, the absolute address of the code segment can be obtained only when it is loaded. Before loading, we only know the relative address, during the loading process, the operating system randomly assigned an absolute address (notified) based on the memory space )!
When other processes want to use this absolute address, map the code and data in the current virtual memory to the address space of other processes.

Bytes ---------------------------------------------------------------------------------------------------------------
Static link: relocated during connection;
Static Shared Library: No relocation is required;
Dynamic Shared Library: relocated during loading;
Dynamic Shared Library:Virtual Memory is allocated during loading. The first address of each dynamic library must be relocated-shared. However, the code segment of the dynamic shared library may generate Code related to the address: at this time, we need-fPIC to help us convert the address-related code in the code segment into address-independent code. Multiple code segments in the shared object can be easily used (read-only) and Data Segment (read/write); if we do not make the address-independent code, then when the shared library is reused, the virtual memory of a process is mapped to another process, you can calculate the internal code of the shared object, but in this way, you must reserve a space, which is contrary to the automatically allocated space. Bytes ---------------------------------------------------------------------------------------------------------------
[Code segment irrelevant code implementation]:
<1> internal:Reserve the offset to calculate the current address, that is, it is irrelevant to the absolute address.
Calls and redirects functions within the module;
Module Internal data access.
<2> External:Find the absolute address based on the address dependency/symbol table,
Inter-module data access; ---> the global variable address segment (. got segment) stored in this file, ATT: Not an executable file
Inter-module function call/jump; ---> the function reference address segment (. got. plt segment) saved to this file, ATT: Not an executable file
Att:. got segment stores the symbols and addresses of the global variables in this file. To use this variable, you only need to index it in the segment.
Att:. got. plt contains three items
<1>. dynamic segment address. You can use a function name to index the dynamic link symbol table to find the referenced address;
<2> store the ID of the Link Library of this module. For example, test is stored in test. so.
<3> stores the _ dll_runtime_resolve () function address to bind the address based on the address and symbol.


[In short]
Load shared objects:Ensure that the internal code segment of the shared object required by multiple processes has nothing to do with the absolute address. The data/functions related to the absolute address are stored in the. dynamic segment of each shared object after the dynamic link.

Void main (){
CPU control is transferred to the dynamic linker;
The operating system tells the dynamic linker about the basic information of executable files (including the entry address and segment );
The dynamic linker uses its own static link to initiate a static link to a specific address in the memory;
View the DT_NEED in the. dynamic segment of the executable file to find the shared object file on which the current file depends,

While (each dynamic object mapped to a dependency ){
View the. dynamic segment of the dynamic Object and check whether the object depends on other objects. If the object depends on the object, return to the previous loop;

Merges the symbol table in the current dynamic object file into the global symbol table in the virtual space;
Load and map the global variables and static local variables in the current dependent file to the static zone in the virtual memory;
Store executable files and local variables of dependent files in the stack. The Stack's usage will be automatically destroyed when it leaves the stack;
Map Program code to the virtual memory program code area;
If (all dependent objects are loaded)
Break;
}/* ELF and LInux Process Virtual Space ing completed */

The entry address for transferring CPU control to executable files;
Execute the executable file;
Process Virtual Space --> Physical Space
/* The ing between the virtual space and the physical space is completed */
}