Dynamic Link (1). Got and FPIC

1> key to the dynamic link process: load as needed. If other programs also need this module, use the dynamic linker link to locate the required function entry through address relocation.

 

2> the final loading address of the dynamic link library is not determined during compilation.

 

3> when a shared object is created, you cannot assume the specific location of the object in the virtual address space. The base address is reset during loading.

 

4> in this case, the executable file can determine its starting position in the virtual address space. It can select a fixed space address, for example, in Linux, 0x08040000 windows 0x0040000

 

5> relocation during loading: the idea is to do not relocate the reference of all absolute addresses during the connection, but deduce it for loading. Once the loading address is determined, then the system is relocated to the absolute address.

 

6> when the link is relocated, when the load is relocated, Windows calls the base address reset.

 

7> address-independent code: It is expected that the shared commands in the program do not need to be changed because of the load address changes during loading. The basic idea of implementation is as follows: separate the modified parts of the command and put them together with the data, so that the command part can remain unchanged, and the data part can have a backup in each process. (PIC)

 

8> divide the modules in the shared object into the module internal reference and the module external reference. Different reference methods can also be divided into command reference and data access.

 

9> call _ i686.get _ pc_thunk.cx assembly code: mov % (ESP) % (ECx) to the current instruction PC

 

10> inter-module data access: Elf creates a pointer array pointing to a global variable in the Data Segment, also known as the Global Offset Table (got ). when accessing global variables, the program first finds the got and then indexes it based on the address corresponding to the variables in got.

 

11> the dynamic linker searches for the address of each variable when loading the module, and then fills in the got representation. Because. Got is placed in the Data Segment, because the. Got segment itself is placed in the data segment, it can be modified when the module is loaded, and each process has an independent copy, which is not affected by each other.

 

12> during compilation of the elf shared library, global variables in the module are considered as global variables defined in other modules by default, and then passed. got to implement variable access (Note :. got segments are in elf executable files.) When the shared module required by ELF is loaded, if a global variable has a copy in the executable file, then the dynamic linker points the corresponding address in the got to the copy.

 

13>-the PIC address is irrelevant.-FPIC generates code in cross-module mode.

 

14> when the dynamic link file is loaded by Elf and linked by the dynamic linker, fill in. when the got item is used, its data segment has an independent copy in each process. The global variables in the shared object are actually no different from the global variables defined in the program. Any process. You can only access your own copy. It does not affect other processes.

 

15> gcc-shared XXX. c-o XXX. the so command will generate a code that does not use address-independent code, but relocate the shared object when using the load, but because it is not address-independent, it cannot be shared by multiple processes.