动态库加载出错,cannot restore segment prot after reloc: Permission denied以及为何编译动态库需要-fPIC

项目中碰到的问题,编译好的so文件,放到其他机器上去加载,报了错误,cannot restore segment prot after reloc: Permission denied

网上查了一下,原因是selinux的问题,selinux的设置太过严格导致的。解决的办法是在root用户下,修改/etc/selinux/config 文件,

  1. 把SELINUX=enforcing 改成 SELINUX=disabled。  
把SELINUX=enforcing 改成 SELINUX=disabled。

然后,保存关闭,重启机器就可以了。

另外还有一个暂时关闭的方法,就是 /usr/sbin/setenforce 0 。

此外呢,我自己在犄角旮旯里发现了另外一个方法,举个例子,你碰到问题的so文件是test.so,

那么

  1. chcon -t texrel_shlib_t test.so   
chcon -t texrel_shlib_t test.so 

就可以了。不过呢,这个命令只能修改一个so,如果想让你的系统以后都不会碰到这个错误,那最好还是采用修改文件

的方式。

如果你只是来看怎么解决这个问题的,那下面的就不用看了,下面是说gcc的编译命令-fPIC的作用。源自点击打开链接。记住,-fPIC是编译命令,-shared是链接命令。

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

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

from 《 Binary Hacks:黑客秘笈100选

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

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

让我们来进行一个实验:
  1. #include <stdio.h>   
  2. void func() {  
  3.     printf(" ");  
  4.     printf(" ");  
  5.     printf(" ");  
  6. }  
    #include <stdio.h>
    void func() {
        printf(" ");
        printf(" ");
        printf(" ");
    }

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

阅读上述生成的汇编代码,则可以知道PIC版本通过PLT(Procedure Linkage Table)调用printf。
  1. $ grep printf fpic-no-pic.s  
  2.          call printf  
  3.          call printf  
  4.          call printf  
  5. $ grep printf fpic-pic.s  
  6.          call printf@PLT  
  7.          call printf@PLT  
  8.          call printf@PLT  
    $ grep printf fpic-no-pic.s
             call printf
             call printf
             call printf
    $ grep printf fpic-pic.s
             call printf@PLT
             call printf@PLT
             call printf@PLT
下面,编译共享库
  1. $ gcc -shared -o fpic-no-pic.so fpic.c  
  2. $ gcc -shared -fPIC -o fpic-pic.so fpic.c  
    $ gcc -shared -o fpic-no-pic.so fpic.c
    $ gcc -shared -fPIC -o fpic-pic.so fpic.c
这 些共享库的动态节(dynamic section)用readelf阅读的话,非PIC版本中有TEXTREL输入方法(需要在text内进行再配置),并且RELCOUNT(再配置的数 量)为5 -- 比PIC版本的多3个。多出三个是因为printf()的调用进行了3次。
  1. $ readelf -d fpic-no-pic.so | egrep 'TEXTREL|RELCOUNT'  
  2.  0x00000016 (TEXTREL)                  0x0  
  3.  0x6ffffffa (RELCOUNT)                 5  
  4. $ readelf -d fpic-pic.so | egrep 'TEXTREL|RELCOUNT'  
  5.  0x6ffffffa (RELCOUNT)  2  
    $ readelf -d fpic-no-pic.so | egrep 'TEXTREL|RELCOUNT'
     0x00000016 (TEXTREL)                  0x0
     0x6ffffffa (RELCOUNT)                 5
    $ readelf -d fpic-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。
  1. #! /bin/sh   
  2.   rm -f *.o *.so  
  3.   num=1000  
  4.   for i in `seq $num`; do  
  5.       echo -e "#include <stdio.h>\nvoid func$i() {" >fpic$i.c  
  6.       #ruby -e "10000.times { puts 'printf(\" \");' }" >>fpic$i.c   
  7.       perl -e 'print("printf(\" \");\n"x10000);' >>fpic$i.c  
  8.       echo "}" >> fpic$i.c  
  9.       gcc -o fpic-no-pic$i.o -c fpic$i.c  
  10.       gcc -o fpic-pic$i.o -fPIC -c fpic$i.c  
  11.   done  
  12.   gcc -o fpic-no-pic.so -shared fpic-no-pic*.o  
  13.   gcc -o fpic-pic.so -shared fpic-pic*.o  
  14.   
  15.   echo "int main() { return 0; }" >fpic-main.c  
  16.   gcc -o no-pic-load fpic-main.c ./fpic-no-pic.so  
  17.   gcc -o pic-load fpic-main.c ./fpic-pic.so  
  18.   
  19.   echo "int main() {" >main.c  
  20.   for i in `seq $num`; do echo "func$i();"; done >>main.c  
  21.   echo "}" >>main.c  
  22.   gcc -o fpic-no-pic main.c ./fpic-no-pic.so  
  23.   gcc -o fpic-pic main.c ./fpic-pic.so  
  #! /bin/sh
    rm -f *.o *.so
    num=1000
    for i in `seq $num`; do
        echo -e "#include <stdio.h>\nvoid func$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 -o fpic-no-pic.so -shared fpic-no-pic*.o
    gcc -o fpic-pic.so -shared fpic-pic*.o

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

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

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

  1. $ repeat 3 time ./no-pic-load  
  2. 2.15s total : 0.29s user 0.48s system 35% cpu  
  3. 0.56s total : 0.25s user 0.31s system 99% cpu  
  4. 0.55s total : 0.30s user 0.25s system 99% cpu  
  5. $ repeat 3 time ./pic-load  
  6. 0.02s total : 0.00s user 0.00s system 0% cpu  
  7. 0.00s total : 0.00s user 0.01s system 317% cpu  
  8. 0.00s total : 0.00s user 0.00s system 0% cpu  
    $ repeat 3 time ./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 3 time ./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+Debian GNU/Linux sarge+GCC 3.3.5。

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

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

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值