objdump 显示的地址是最终地址还是只是偏移量？

Question

假设这个C 代码，用gcc file.c 编译：

int main(){
 return 0;
}

使用objdump 生成的输出：

0000000000000660 <main>:
660:    55                      push   %rbp
661:    48 89 e5                mov    %rsp,%rbp
664:    b8 00 00 00 00          mov    $0x0,%eax
669:    5d                      pop    %rbp
66a:    c3                      retq   
66b:    0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

注意第一个地址是660。

这是来自GDB的相同输出：

0x555555554660 <main>                   push   %rbp
0x555555554661 <main+1>                 mov    %rsp,%rbp
0x555555554664 <main+4>                 mov    $0x0,%eax
0x555555554669 <main+9>                 pop    %rbp
0x55555555466a <main+10>                retq

注意每个地址左侧添加的5s。

这是我的问题：

1- 左边的5s 是什么？为什么 objdump 没有它们？

2- 这些只是偏移量吗？或最终地址硬编码在二进制文件中，将加载到虚拟内存中。

3- 如果这些是偏移量，那么常规可执行文件和PIE 之间有什么区别？我认为只有 PIE 代码是位置独立的，并且在加载时分配了随机地址，我没有使用 -fpie 选项进行编译。我也用过-fno-pie，没什么区别。

Answer 1

1- 左边的 5 是什么？为什么 objdump 没有它们？

555…555₁₆ 是 1000…000₁₆ 的三分之一。你看到多个五只是因为有人将某个特定的内存区域分成三部分。 objdump 没有它们，因为它只是显示偏移量。

2- 这些只是偏移量吗？或最终地址硬编码在二进制文件中，将加载到虚拟内存中。

它们是相对于它们所在程序部分的开始的偏移量。

3- 如果这些是偏移量，那么常规可执行文件和 PIE 之间有什么区别？我认为只有 PIE 代码是位置独立的，并且在加载时分配了随机地址，我没有使用 -fpie 选项进行编译。我也用过 -fno-pie 并没有什么不同。

与位置无关的可执行文件在程序执行期间计算其地址。它使用基址寄存器或提供给它的其他信息来定位事物，或者它使用与程序计数器相关的地址，或与程序位置无关的其他寻址形式。

相反，不独立于位置的程序可以使用绝对形式的寻址。但是，绝对地址不一定内置在目标模块中。目标模块中的地址可能仍然是相对于程序段或其他参考点的偏移量。当程序被加载时，加载器选择程序段的放置位置，并调整指令中的所有地址，将它们从偏移地址更改为绝对地址。目标模块和最终的可执行文件包含描述需要这些“修复”的所有位置的数据结构。

位置无关代码可以同时在两个不同进程中的两个不同虚拟内存地址上使用。因为它使用相对形式的寻址来构造它的所有地址，所以代码的位置是无关紧要的。使用加载程序固定地址的代码与特定地址相关联；加载程序完成后，代码在其指令中嵌入了特定地址，因此无法将其移动到其他位置。