为什么 LD 以这种方式为 Ubuntu 18.04 上的 ELF64 映射部分答案

【问题标题】：Why does LD map sections in this manner for ELF64 on Ubuntu 18.04为什么 LD 以这种方式为 Ubuntu 18.04 上的 ELF64 映射部分
【发布时间】：2020-07-27 20:41:00
【问题描述】：

使用

GNU ld（用于 Ubuntu 的 GNU Binutils）2.30

在生成文件中

应用程序：App.o Init.o SubRtx.o ld -oApp SubRtx.o Init.o App.o 应用程序.o：应用程序.asm nasm -g -felf64 App.asm -oApp.o 初始化.o：初始化.asm nasm -g -felf64 Init.asm -oInit.o SubRtx.o：SubRtx.asm nasm -g -felf64 SubRtx.asm -oSubRtx.o 干净的： rm *.o 应用程序

分段按以下方式映射。

[1] .text PROGBITS 4000b0 0000b0 00023f 00 AX 0 0 16 [2] .rodata PROGBITS 4002f0 0002f0 000018 00 A 0 0 16 [3] .data PROGBITS 600310 000310 0000d0 00 WA 0 0 16

在我的汇编文件中，节被简单地声明为 section .data 和 section .rodata 并且设计上 App.o 是唯一的带有 .data 部分的文件，因此它被映射为 @ 0x600310

我可能会对 Windows 甚至 ELF32 感到困惑，但我似乎想记住默认情况下开始的段 @ 甚至 4K 边界。 IE：.data 将是@0x600000 或至少为0x601000，但是将TEXT 部分的内容从0x400000 复制到DATA，然后DATA 直到0x310 才开始似乎是不必要的浪费。

有意地，我的应用程序是完全独立的（静态链接），并且仅通过 SYSCALL 与操作系统交互。代码按预期工作，我什至删除了 0x600000 -> 0x60030f 中的内容而没有不利影响，但我仍然很好奇为什么会发生这种情况。

【问题讨论】：

标签： nasm ubuntu-18.04 ld elf

【解决方案1】：

分段按以下方式映射。

这些是部分，而不是段（它们不是一回事）。

.data 将是 @ 0x600000

不可能将可执行文件中从偏移量0x310 开始的数据段mmap 移动到内存中不等于0x310 模页面大小的任何位置。

另请参阅this 或this 答案。

【讨论】：