在x64位Linux上生成动态链接库必须使用编译选项-fPIC的问题_正清技术博客
来源:百度文库 编辑:神马文学网 时间:2024/04/28 22:41:42
在 Linux 下制作动态链接库,“标准” 的做法是编译成位置无关代码(Position Independent Code,PIC),然后链接成一个动态链接库。经常遇到的一个问题是 -fPIC 是不是必需,因为好像不加经常也能正常运行,只是创建 .so 的时候会有一个警告。
搜索、试验了一下,答案似乎是这样:
(1) 通常的建议是始终加上 -fPIC 生成位置无关代码;
(2) AMD64 下,必须使用位置无关代码,否则连接失败:
relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
(3) IA32 下,连接成功,但有警告:
warning: creating a DT_TEXTREL in object.
这样的 .so 文件可以完全正常工作。
可执行文件在链接时就知道每一行代码、每一个变量会被放到线性地址空间的什么位置,因此这些地址可以都作为常数写到代码里面。对动态库,这就不行了,这要等到加载时才知道。无非下面两种方法:
(1) 可重定位代码(relocatable code):Windows DLL 以及不使用 -fPIC 的 Linux SO。
生成动态库时假定它被加载在地址 0 处。加载时它会被加载到一个地址(base),这时要进行一次重定位(relocation),把代码、数据段中所有的地址加上这个 base 的值。这样代码运行时就能使用正确的地址了。
(2) 位置无关代码(position independent code):使用 -fPIC 的 Linux SO。
这样的代码本身就能被放到线性地址空间的任意位置,无需修改就能正确执行。通常的方法是获取指令指针(如 IA32 的 EIP 寄存器)的值,加上一个偏移得到全局变量/函数的地址。
PIC vs. relocatable:
(1) PIC 的缺点主要就是代码有可能长一些。例如 IA32,由于不能直接使用 [EIP+constant] 这样的寻址方式,甚至不能直接将 EIP 的值交给其他寄存器,要用到 GOT(global offset table)来定位全局变量和函数。这样导致代码的效率略低。
(2) PIC 的加载速度稍快,因为不需要做重定位。
(3) 多个进程引用同一个 PIC 动态库时,可以共用内存。这一个库在不同进程中的虚拟地址不同,但操作系统显然会把它们映射到同一块物理内存上。对于可重定位代码,则必须为每个库都在物理内存中复制一份副本,因为需要修改其中的地址。当然,主流现代操作系统都启用了分页内存机制,这使得重定位时可以使用 COW(copy on write)来节省内存(32 位 Windows 就是这样做的);然而,页面的粒度还是比较大的(例如 IA32 上是 4KiB),至少对于代码段来说能节省的相当有限。
注:对于 AMD64,由于 AMD64 实现了 [RIP+constant] 的寻址方式,第 (1) 点不成立。
这样,把动态库编译成 PIC 只有好处没有坏处,因而 Linux AMD64 要求用于生成动态库的目标文件必须使用 -fPIC 编译也合情合理了。
搜索、试验了一下,答案似乎是这样:
(1) 通常的建议是始终加上 -fPIC 生成位置无关代码;
(2) AMD64 下,必须使用位置无关代码,否则连接失败:
relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
(3) IA32 下,连接成功,但有警告:
warning: creating a DT_TEXTREL in object.
这样的 .so 文件可以完全正常工作。
可执行文件在链接时就知道每一行代码、每一个变量会被放到线性地址空间的什么位置,因此这些地址可以都作为常数写到代码里面。对动态库,这就不行了,这要等到加载时才知道。无非下面两种方法:
(1) 可重定位代码(relocatable code):Windows DLL 以及不使用 -fPIC 的 Linux SO。
生成动态库时假定它被加载在地址 0 处。加载时它会被加载到一个地址(base),这时要进行一次重定位(relocation),把代码、数据段中所有的地址加上这个 base 的值。这样代码运行时就能使用正确的地址了。
(2) 位置无关代码(position independent code):使用 -fPIC 的 Linux SO。
这样的代码本身就能被放到线性地址空间的任意位置,无需修改就能正确执行。通常的方法是获取指令指针(如 IA32 的 EIP 寄存器)的值,加上一个偏移得到全局变量/函数的地址。
PIC vs. relocatable:
(1) PIC 的缺点主要就是代码有可能长一些。例如 IA32,由于不能直接使用 [EIP+constant] 这样的寻址方式,甚至不能直接将 EIP 的值交给其他寄存器,要用到 GOT(global offset table)来定位全局变量和函数。这样导致代码的效率略低。
(2) PIC 的加载速度稍快,因为不需要做重定位。
(3) 多个进程引用同一个 PIC 动态库时,可以共用内存。这一个库在不同进程中的虚拟地址不同,但操作系统显然会把它们映射到同一块物理内存上。对于可重定位代码,则必须为每个库都在物理内存中复制一份副本,因为需要修改其中的地址。当然,主流现代操作系统都启用了分页内存机制,这使得重定位时可以使用 COW(copy on write)来节省内存(32 位 Windows 就是这样做的);然而,页面的粒度还是比较大的(例如 IA32 上是 4KiB),至少对于代码段来说能节省的相当有限。
注:对于 AMD64,由于 AMD64 实现了 [RIP+constant] 的寻址方式,第 (1) 点不成立。
这样,把动态库编译成 PIC 只有好处没有坏处,因而 Linux AMD64 要求用于生成动态库的目标文件必须使用 -fPIC 编译也合情合理了。
在x64位Linux上生成动态链接库必须使用编译选项-fPIC的问题_正清技术博客
linux 下链接库的生成使用
用gcc编译生成动态链接库*.so文件的方法
Linux编译动态库
gcc编译选项介绍(转) - 技术文档 - 程序开发 Linux时代 - 开源、自由、共享 - 中国最大的Linux技术社区
动态生成与编译(八)----动态编译
股票如何在技术图形上判断支撑位和阻力位_畅游股市 小敏的博客
Linux怎样编写和编译动态库
linux静态链接库与动态链接库的区别及动态库的创建
均价线在技术分析上的使用问题
Re: 2.6驱动编译,给gcc 增加选项参数问题? - China Linux Foru...
动态生成与编译(二)----CodeDOM的类层次结构
动态生成与编译(九)----CodeDOM的局限
linux静态链接库与动态链接库的区别创建
构建ARM Linux交叉编译工具链 - 中国人是有骨气的 - 51CTO技术博客
linux中编译静态库(.a)和动态库(.so)的基本方法
C++Builder中动态库的链接问题
动态生成与编译(一)----入门
Linux 2.6.19.x 内核编译配置选项简介
【C++】编写动态链接库(DLL) __stdcall_【wjxgzz的博客】
动态生成与编译(七)----根据CodeDOM生成源代码
LINUX动态链接库高级应用(etc/ld.so.conf)共享动态链接库
linux宝库/编程技术/创建和使用库:静态、共享和动态
Linux动态连接原理 - 编译相关 - wylhistory