编译GNU/Linux共享库, 为什么要用PIC编译?

一直以为不管是编译共享库还是静态库，中间生成的目标文件(.o文件)是没有区别的，区别只在:最后是用-shared编译还是用ar打包；可是事情的真相并不是这样的：

from 《Binary Hacks:黑客秘笈100选》

本hack中，我们来研究编译共享库时，为什么要用PIC(选项)编译？

通常编译GNU/Linux共享库时，把各个.c文件编译编译成PIC(Position Independent Code,位置无关代码)。但是，实际上不用PIC编译的话也可以编译共享库。那么使用PIC还有意义吗？

让我们来进行一个实验：
 

   #include<stdio.h>
    void func(){
       printf(" ");
       printf(" ");
       printf(" ");
    }

用PIC编译必须把参数-fpic或-fPIC传给gcc，-fpic可以生成小而高效的代码，但是不同的处理器中-fpic生成的GOT(GlobalOffset Table,全局偏移表)的大小有限制，另一方面，使用-fPIC的话，任何处理器都可以放心使用。在这里，使用-fPIC。(在X86中使用-fpic和-fPIC没有任何区别)。
    $ gcc -ofpic-no-pic.s -S fpic.c
    $ gcc -fPIC-o fpic-pic.s -S fpic.c

阅读上述生成的汇编代码，则可以知道PIC版本通过PLT(Procedure Linkage Table)调用printf。
    $ grepprintf fpic-no-pic.s
            call printf
            call printf
            call printf
    $ grepprintf fpic-pic.s
            call printf@PLT
            call printf@PLT
            call printf@PLT
下面，编译共享库
    $ gcc-shared -o fpic-no-pic.so fpic.c
    $ gcc-shared -fPIC -o fpic-pic.so fpic.c

这 些共享库的动态节(dynamicsection)用readelf阅读的话，非PIC版本中有TEXTREL输入方法(需要在text内进行再配置)，并且RELCOUNT(再配置的数量)为5 -- 比PIC版本的多3个。多出三个是因为printf()的调用进行了3次。
    $ readelf -dfpic-no-pic.so | egrep 'TEXTREL|RELCOUNT'
    0x00000016(TEXTREL)                 0x0
    0x6ffffffa(RELCOUNT)                5
    $ readelf -dfpic-pic.so | egrep 'TEXTREL|RELCOUNT'
    0x6ffffffa (RELCOUNT)  2

PIC版本的RELCOUNT非0是由于gcc在缺省时使用的是包含在启动文件里的代码。若加-nostartfiles选项，则RELCOUNT值为0。

PIC和非PIC共享库的性能对比
上面例子阐述了非PIC版本运行时(动态运行时)需要5个地址的再分配。那么，若在配置的数量大增时会出现什么样的情况呢？

运行下面的shell脚本，用非PIC版本和PIC版本编译含有1000万次printf()调用的共享库，和相应的可执行文件fpic-no-pic和fpic-pic。

    #!/bin/sh
    rm -f *.o*.so
   num=1000
    for i in`seq $num`; do
       echo -e "#include <stdio.h>\nvoidfunc$i() {" >fpic$i.c
       #ruby -e "10000.times { puts 'printf(\" \");' }">>fpic$i.c
       perl -e 'print("printf(\" \");\n"x10000);'>>fpic$i.c
       echo "}" >> fpic$i.c
       gcc -o fpic-no-pic$i.o -c fpic$i.c
       gcc -o fpic-pic$i.o -fPIC -c fpic$i.c
    done
    gcc -ofpic-no-pic.so -shared fpic-no-pic*.o
    gcc -ofpic-pic.so -shared fpic-pic*.o

    echo "intmain() { return 0; }" >fpic-main.c
    gcc -ono-pic-load fpic-main.c ./fpic-no-pic.so
    gcc -opic-load fpic-main.c ./fpic-pic.so

    echo "intmain() {" >main.c
    for i in`seq $num`; do echo "func$i();"; done>>main.c
    echo "}">>main.c
    gcc -ofpic-no-pic main.c ./fpic-no-pic.so
    gcc -ofpic-pic main.c ./fpic-pic.so

两个版本程序，运行结果如下：非PIC版本首次运行时间2.15秒，第二次以后大约0.55秒，而PIC版本的首次用了0.02秒，第二次以后用了0.00秒。

    $ repeat 3time ./no-pic-load
    2.15s total: 0.29s user 0.48s system 35% cpu
    0.56s total: 0.25s user 0.31s system 99% cpu
    0.55s total: 0.30s user 0.25s system 99% cpu
    $ repeat 3time ./pic-load
    0.02s total: 0.00s user 0.00s system 0% cpu
    0.00s total: 0.00s user 0.01s system 317% cpu
    0.00s total: 0.00s user 0.00s system 0% cpu
main() 本身是空的，可以知道非PIC版本动态链接时的再分配需要2.15~0.55秒。运行环境Xeon-2.8GHz+DebianGNU/Linux sarge+GCC 3.3.5。

非PIC版本的缺点不仅是在运行时再配置上花时间。为了更新再配置部分的代码，将会发生这样的情况(下载textsegment里需要再配置的页->更新->进行copy on write->不能与其他路径和text共享)。

另外比较非PIC版本的fpic-no-pic.so和PIC版本的fpic-pic.so的大小，前者268M，后者134M，差别很明显。用readelf-S查看节头，会有以下区别：
                .rel.dyn     .text
非PIC           152MB        114MB
PIC             0MB          133MB

非PIC版本的代码(.text)比PIC版本的小，但再配置所需要的信息占很大的空间。


转自：http://lcinx.blog.163.com/blog/static/43494267201121211316355/