c - -pie 究竟做了什么？

Question

我 file/bin/ls 并得到输出:

/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped

我发现原因是我的 gentoo 正在使用 -pie 编译所有内容。

如果我将 -nopie 传递给 gcc，我将得到正确的答案:

a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped

此外，我在 building a .so that is also an executable 找到了一些东西.它使用 -pie 使 DSO 可执行。

在gcc的man page中，有简要的描述:

-pie
Produce a position independent executable on targets that support it.

所以我想知道 -pie 到底做了什么？它如何使我的可执行文件被识别为共享对象？

Answer 1

“可执行文件”和“共享对象”之间的区别在很大程度上是人为的。 file 命令显示的是 ELF e_type header 是 ET_EXEC 还是 ET_DYN。这是一个相当技术性的区别，与加载器如何对待它们有关。 file(通过它的魔法文件)可能应该通过寻找其他特征来区分“共享库”意义上的“共享对象”和“PIE 可执行文件”，例如 PT_INTERP 程序头(库通常没有)或者可能是入口点地址(尽管有些库似乎没有意义)。

为了解决 -pie 的问题，它生成一个可以加载到任意基地址的可执行文件，而不是加载地址固定在 ld 的“普通”可执行文件>-时间。它们使用与共享库中使用的相同类型的位置无关代码和加载 header ，它们也可以在任意地址加载(并且需要可以在任意地址加载，因为任何固定地址都可能已经被占用由主要的可执行文件或另一个库)。 PIE 通常被认为是一种强化机制(允许地址随机化影响主程序中代码和数据的地址)，但它也可以有其他用途，例如使二进制文件更适合无 MMU 系统。