Reprinted from:
https://www.cnblogs.com/cswuyg/p/3830703.html
Recently looking at the basics of Linux programming intended for some of the more interesting knowledge do some summary notes, paper focuses fPIC unfold, learning to see the end of the reference text.
In the Linux system, dynamic link file called Dynamic Shared Object (DSO, Dynamic Shared Objects), referred to as a shared object, and is usually .so file extension. On Windows systems, it is called dynamic link libraries (Dynamic Linking Library), many with .dll extension. Here only memo Linux shared object.
When implementing a shared object, compile and link the most general command line:
g++ -fPIC -shared test.cc -o lib.so
or it could be:
g++ -fPIC test.cpp -c -o test.o
ld -shared test.o -o lib.so
The above command line -shared shown to produce shared libraries, and -fPIC indicates that the use of position-independent code. PIC: Position Independent Code.
When compiling under Linux shared library, you must add -fPIC parameters, otherwise there will be a link in the error message (AMD64 machines have information that will be this wrong, but I also appeared in the Inter machine):
/usr/bin/ld: test.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC test.o: could not read symbols: Bad value collect2: ld returned 1 exit status
How to confirm a shared object is PIC it?
readelf -d foo.so | grep TEXTREL
If there is any output on top of the shell, then this is not foo.so PIC. Represents TEXTREL code segment address relocation table, PIC shared objects not contain any code relocation table.
What fPIC purpose is
? Shared objects may be loaded different processes to different locations, if the shared object instruction uses an absolute address, the external module address, then we must make adjustments to this address according to the loading position of the relevant module in the shared object is loaded , that is, to modify these addresses, it can access the right in the corresponding process, which is modified to a segment can not be achieved multi-process a shared physical memory, they must have a copy of the physical memory in each process. fPIC instruction is to allow multiple processes to use the same shared object can share as much physical memory behind those places related to the absolute address, the address to access external modules are pulled out to ensure that the contents of the code snippet can the same multi-process, sharing.
Pulled out of this part of the special instruction, after the address, into a place called the GOT (Global Offset Table), which is placed in the data segment, each process has its own copy of the contents inside may be the address of a variable , address of the function, different processes its content is likely to be different, and this part is to be isolated from "address relevant" content. When the module is loaded, the table of contents will GOT populated (in the absence of delayed binding). To access to the code segment that GOT, by a similar window of call / pop / sub obtained instruction address of the corresponding item GOT.
For access module global variables, in order to solve the executable file with the same module you may have a problem with global variables (in this case, global variables in the module will be covered as a global variable in the executable file), the global module GOT indirect variable access is also accessible through.
This way, each access global variables, external functions are required to calculate the position in the GOT, and then accessing a value corresponding to the variable term, the calling function. From the running performance, the ratio to be loaded almost relocation. Relocation is not used when loading fPIC parameter, a code segment need relocation table, all the correction special address during the loading, there is no need to calculate the position of GOT and indirect access to future runs. (However, I tested it on my machine, when compiled and linked shared libraries, can not not use fPIC parameters, the system may require a majority must have fPIC)
If you go to the content of GOT is calculated at the time of loading, it will affect the loading speed, so there
late binding
(Lazy Binding), only to fill up with GOT. It is used to
the PLT (Procedure Linkage the Table)
: each of which is a short code, which corresponds to the function of the present operation of the module to be referenced. When the function is called, first here, and then to the GOT. The first time the function is called, into the PLT skip loader, the loader real address calculation function, and then writes the address corresponding item GOT, after the call jump function directly from the record position of GOT PLT. This also reduces multiple calls to calculate GOT position many times running.
PIC shared object will have a relocation table, the absolute address of the data segment GOT, data reference, these are the need for relocation.
readelf -r Lib.so
Relocation table can be seen that the shared object, .rel.dyn reference data is corrected, .rel.plt correction function is referenced.
Learning materials: "Programmer's self-cultivation - link is loaded with the library."