Interpretation of GOT tables and PLT tables in ELF files

The ELF can generate a special code-the location-independent code (Position-independent code,pic). The user uses-fpic to instruct the GNU compilation system to generate PIC code for GCC. It is the basis for implementing shared libraries or sharing executable code. The peculiarity of this code is that it can be loaded into the memory address space of any address execution. It is also convenient for the loader to dynamically link shared libraries in the process.
The PIC implementation uses the fact that the distance between any instruction in the code snippet and any variable in the data segment is a constant that is independent of the absolute memory location of the code snippet and data segment. Therefore, the compiler creates a table where the data segment begins. Called the Global offset table. GOT). The Got contains a table of each global data target referenced by this target module. The compiler also generates a relocation record for each table in got. At load time, the dynamic linker repositions each table in got so that it contains the correct absolute address. Pic Code is implemented in code to refer to each global variable indirectly through got, so that the simple data references in the code become complex and must be added to the instructions that got the appropriate contents of the table. The reference to read-only data is also based on the same principle, so adding the code compiled by the IC is much more expensive than the usual code.

If an elf executable needs to invoke any function defined in a shared library, then it has its own got and PLT (Procedure linkage table, process-linked tables). The interaction between the two sections can implement lazy binding (lazy binging), which defers binding of the process address until the function is called for the first time. In order to implement delay binding, the first three entries of the GOT are special: Got[0] contains the address of the. Dynamic segment, which contains the information that is used to bind the process address, such as the position of the symbol and the relocation information; GOT[1] contains the identity of the dynamic linker; GOT[2] contains the entry point for the dynamic linker's deferred binding code. Other got are the address of a global variable or function to be referenced by this module. The PLT is a code sequence that appears as an array of 16-byte (32-bit Platform) Table objects. Where Plt[0] is a special table, it jumps to the dynamic linker execution; each function defined in the shared library and called by this module has a table in the PLT, starting with plt[1]. The module's call to the function is transferred to the corresponding PLT table, which is composed of three instructions. The first instruction is to jump to the address value of the corresponding got store. The second instruction presses the corresponding ID of the function into the stack, and the third instruction jumps to plt[o] to invoke the address of the dynamic linker parsing function, and the real address of the function is stored in the corresponding got table. The called function got the address value of the second instruction in the corresponding PLT table for the original address stored in the corresponding table, after the function is first called. The value in the Got table is the true address of the function. Therefore, the first call to the function is more expensive. However, each subsequent invocation will only cost an instruction and an indirect memory reference.