请问gcc里的参数-fPIC的一些问题

yongzhi

加上-fPIC参数后，编译后的文件和没有加这个参数的文件，有什么区别呢，在代码里面做了什么修改能增强它的可重定位性，或者说位置无关性呢？
而且，用没有加这个参数的编译后的共享库，也可以使用，它和加了参数后的使用起来又有什么区别呢
谢谢

印随

可能是两个原因：
1：gcc默认开启-fPIC选项
2：loader使你的代码位置无关

yjm0573

一般都用于编译共享库

baohuaihuai

我的理解.
不加fPIC编译出来的so,是要再加载时根据加载到的位置再次重定位的.(因为它里面的代码并不是位置无关代码)
如果被多个应用程序共同使用,那么它们必须每个程序维护一份so的代码副本了.(因为so被每个程序加载的位置都不同,显然这些重定位后的代码也不同,当然不能共享)
这样就失去了共享库的好处,实际上和静态库的区别并不大,在运行时占用的内存是类似的,仅仅是二进制代码占的硬盘空间小一些.而且在加载时才重定位的开销也很大(这一点使得这种做法更加没有意义).

[ 本帖最后由 baohuaihuai 于 2007-12-28 11:54 编辑 ]

baohuaihuai

事实上有比不用fPIC编译so更加bh的...........那就是..用fPIC选项制作静态库.

accelerator

原帖由 baohuaihuai 于 2007-12-28 11:52 发表
我的理解.
不加fPIC编译出来的so,是要再加载时根据加载到的位置再次重定位的.(因为它里面的代码并不是位置无关代码)
如果被多个应用程序共同使用,那么它们必须每个程序维护一份so的代码副本了.(因为so被每个程 ...

阁下忽略了动态连接库的另外一个非常重要的作用, 动态连接, 这样程序可以支持二进制文件接口, 比如连接libc时一般都使用.so而不是.a, 你总不想在libc更新后重新链接你的程序吧? 实际上这种功能比所谓的share更重要, 应用也更广泛.

baohuaihuai

原帖由 accelerator 于 2007-12-28 12:32 发表


阁下忽略了动态连接库的另外一个非常重要的作用, 动态连接, 这样程序可以支持二进制文件接口, 比如连接libc时一般都使用.so而不是.a, 你总不想在libc更新后重新链接你的程序吧? 实际上这种功能比所谓的shar ...

阁下好象误会了我的意思,我只是针对fPIC在做说明.fPIC与非fPIC的区别,与.so和.a的区别是两回事.虽然我们总是用fPIC来生成so,也从来不用fPIC来生成a.
fPIC与动态链接可以说基本没有关系,libc.so一样可以不用fPIC编译,只是这样的so必须要在加载到用户程序的地址空间时重定向所有表目.

baohuaihuai

因此,不用fPIC编译so并不总是不好.
如果你满足以下4个需求/条件:
1.该库可能需要经常更新
2.该库需要非常高的效率(尤其是有很多全局量的使用时)
3.该库并不很大.
4.该库基本不需要被多个应用程序共享

我认为你的so就完全可以不用fPIC编译.

zx_wing

原帖由 yongzhi 于 2007-12-27 16:36 发表
加上-fPIC参数后，编译后的文件和没有加这个参数的文件，有什么区别呢，在代码里面做了什么修改能增强它的可重定位性，或者说位置无关性呢？
而且，用没有加这个参数的编译后的共享库，也可以使用，它和加了参 ...

从GCC来看，shared应该是包含fPIC选项的，但似乎不是所以系统都支持，所以最好显式加上fPIC选项。参见如下


`-shared'
     Produce a shared object which can then be linked with other
     objects to form an executable.  Not all systems support this
     option.  For predictable results, you must also specify the same
     set of options that were used to generate code (`-fpic', `-fPIC',
     or model suboptions) when you specify this option.(1)

hallowwar

:wink: