linux gcc编译参数： -fPIC

### Date: 2017/5/12

参考：http://blog.sina.com.cn/s/blog_54f82cc201011op1.html     

             http://www.cnblogs.com/cswuyg/p/3830703.html

    -fPIC 作用于编译阶段，告诉编译器产生与位置无关代码(Position-Independent Code)， 则产生的代码中，没有绝对地址，全部使用相对地址，故而代码可以被加载器加载到内存的任意位置，都可以正确的执行。这正是共享库所要求的，共享库被加载时，在内存的位置不是固定的。

        如果不加-fPIC,则加载.so文件的代码段时,代码段引用的数据对象需要重定位, 重定位会修改代码段的内容,这就造成每个使用这个.so文件代码段的进程在内核里都会生成这个.so文件代码段的copy.每个copy都不一样,取决于 这个.so文件代码段和数据段内存映射的位置.

不加fPIC编译出来的so,是要再加载时根据加载到的位置再次重定位的.(因为它里面的代码并不是位置无关代码)。

使用 -fPIC 选项，会生成 PIC 代码。.so 要求为 PIC，以达到动态链接的目的，否则，无法实现动态链接。

non-PIC 与 PIC 代码的区别主要在于 access global data, jump label 的不同。

比如一条 access global data 的指令，

non-PIC 的形势是：ld r3, var1

PIC 的形式则是：ld r3, var1-offset@GOT,意思是从 GOT 表的 index 为 var1-offset 的地方处

指示的地址处装载一个值,即 var1-offset@GOT 处的4个 byte 其实就是 var1 的地址。这个地址只有在运行的时候才知道，

是由 dynamic-loader(ld-linux.so) 填进去的。

再比如 jump label 指令

non-PIC 的形势是：jump printf ，意思是调用 printf。

PIC 的形式则是：jump printf-offset@GOT,意思是跳到 GOT 表的 index 为 printf-offset 的地方处

指示的地址去执行，这个地址处的代码摆放在 .plt section，每个外部函数对应一段这样的代码，其功能是呼叫

dynamic-loader(ld-linux.so) 来查找函数的地址(本例中是 printf)，然后将其地址写到 GOT 表的 index 为 printf-offset 的地方，

同时执行这个函数。这样，第2次呼叫 printf 的时候，就会直接跳到 printf 的地址，而不必再查找了。

GOT 是 data section, 是一个 table, 除专用的几个 entry，每个 entry 的内容可以再执行的时候修改；

PLT 是 text section, 是一段一段的 code，执行中不需要修改。

每个 target 实现 PIC 的机制不同，但大同小异。比如 MIPS 没有 .plt, 而是叫 .stub，功能和 .plt 一样。

可见，动态链接执行很复杂，比静态链接执行时间长;但是，极大的节省了 size，PIC 和动态链接技术是计算机发展史上非常重要的一个里程碑。

   fPIC的目的是什么？共享对象可能会被不同的进程加载到不同的位置上，如果共享对象中的指令使用了绝对地址、外部模块地址，那么在共享对象被加载时就必须根据相关模块的加载位置对这个地址做调整，也就是修改这些地址，让它在对应进程中能正确访问，而被修改到的段就不能实现多进程共享一份物理内存，它们在每个进程中都必须有一份物理内存的拷贝。fPIC指令就是为了让使用到同一个共享对象的多个进程能尽可能多的共享物理内存，它背后把那些涉及到绝对地址、外部模块地址访问的地方都抽离出来，保证代码段的内容可以多进程相同，实现共享。

    抽离出这部分特殊的指令、地址之后，放到了一个叫做GOT（Global Offset Table）的地方，它放在数据段中，每一个进程都有独立的一份，里面的内容可能是变量的地址、函数的地址，不同进程它的内容很可能是不同的，这部分就是被隔离开的“地址相关”内容。模块被加载的时候，会把GOT表的内容填充好（在没有延迟绑定的情况下）。代码段要访问到GOT时，通过类似于window的call/pop/sub指令得到GOT对应项的地址。

    对于模块中全局变量的访问，为了解决可执行文件跟模块可能拥有同一个全局变量的问题（此时，模块内的全局变量会被覆盖为可执行文件中的全局变量），对模块中的全局变量访问也通过GOT间接访问。

    这样子，每一次访问全局变量、外部函数都需要去计算在GOT中的位置，然后再通过对应项的值访问变量、调用函数。从运行性能上来说，比装载时重定位要差点。装载时重定位就是不使用fPIC参数，代码段需要一个重定位表，在装载时修正所有特殊地址，以后运行时不需要再有GOT位置计算和间接访问。（但是，我在自己机子上测试，编译链接共享库时，没法不使用fPIC参数，可能多数系统都要求必须有fPIC）

    如果在装载时就去计算GOT的内容，那么会影响加载速度，于是就有了延迟绑定（Lazy Binding），直到用时才去填充GOT。它使用到了PLT（Procedure Linkage Table）：每一项都是一小段代码，对应于本运行模块要引用的函数。函数调用时，先到这里，然后再到GOT。在函数第一次被调用时，进入PLT跳到加载器，加载器计算函数的真正地址，然后将地址写入GOT对应项，以后的调用就直接从PLT跳到GOT记录的函数位置。这样也减少了运行时多次调用多次计算GOT位置。

    PIC的共享对象也会有重定位表，数据段中的GOT、数据的绝对地址引用，这些都是需要重定位的。

  readelf -r Lib.so

　　可以看到共享对象的重定位表，.rel.dyn是对数据引用的修正，.rel.plt是对函数引用的修正。