C 在链接过程中，饼图文件是否给定了虚拟内存地址？

我用gcc-fpie test.c编译了一个简单的

helloworld

c代码， 现在来看一下使用objdump的二进制代码：

Disassembly of section __TEXT,__text:
__text:
100000f40:  55  pushq   %rbp
100000f41:  48 89 e5    movq    %rsp, %rbp
100000f44:  48 83 ec 10     subq    $16, %rsp
100000f48:  89 7d fc    movl    %edi, -4(%rbp)
100000f4b:  8b 75 fc    movl    -4(%rbp), %esi
100000f4e:  48 8d 3d 5d 00 00 00    leaq    93(%rip), %rdi
100000f55:  b0 00   movb    $0, %al

...

我们可以清楚地看到内存地址仍然是由左边的链接器计算的。

pie

文件不是应该没有静态关联的内存地址吗

---

我的第二个问题是，

pic

文件（如共享库）如何加载到内存中？他们有自己的虚拟地址空间吗？如果是这样，为什么他们需要立场独立？还是将它们加载到进程地址空间

这些不是地址。您应该查看的是PC的相对偏移：

leaq    93(%rip), %rdi

这些表示代码是PIC/PIE

共享库映射到使用它们的每个正在运行的进程中。

---

但是，这些库需要重新定位（以适应程序的地址空间限制），因此使用PIC（位置独立代码，也称为PC相对偏移量）编译。

谢谢，所以在虚拟内存之外有地址空间，每个进程都可以访问？还是它仍然是虚拟内存，但在所有processec之间共享？@Josh：它是否是PIE与内存是否共享无关（程序文本/数据的只读映射总是共享的）。它们不是“文件中的偏移量”，尽管它们可能恰好等于文件中的偏移量。它们是ELF文件的

PT\u load

段中的虚拟（不是运行时虚拟，而是ELF负载映射虚拟）地址。对于PIC/PIE，它们通常从0开始，但可能从任意和非零开始。在运行时，它们被一个常量偏移量移位，该偏移量等于PIC/PIE共享库或程序加载时的地址减去ELF加载映射中的基本虚拟地址。初始化全局数据中的地址引用必须按此偏移量进行调整。。。。。。程序文本不需要调整，因为它不包含任何绝对地址，只包含相对地址，这些地址无论加载到哪里都不会改变。@Josh Sort。。共享库映射到使用它的每个进程中。