《程序员的自我修养——链接、装载与库》读书笔记—— 6.4.1 ELF 文件链接视图和执行视图

对附录中的代码编译（采用静态链接，动态链接的情况复杂些，后续看到动态链接的章节的时候再讨论。可以从下边的编译结果看到，静态链接明显比动态链接的可执行文件大很多）

zqxl@ubuntu:~/work/practice/_6.4_task_vma$ gcc -static SectionMapping.c -o SectionMapping.elf
zqxl@ubuntu:~/work/practice/_6.4_task_vma$ gcc SectionMapping.c -o SectionMapping_dynamic.elf
zqxl@ubuntu:~/work/practice/_6.4_task_vma$ ll
total 852
drwxr-xr-x 2 zqxl zqxl   4096 Sep 10 08:43 ./
drwxr-xr-x 6 zqxl zqxl   4096 Aug 22 17:30 ../
-rw-r--r-- 1 zqxl zqxl    161 Sep 10 08:10 SectionMapping.c
-rwxr-xr-x 1 zqxl zqxl   8312 Sep 10 08:43 SectionMapping_dynamic.elf*
-rwxr-xr-x 1 zqxl zqxl 845232 Sep 10 08:42 SectionMapping.elf*

查看可执行程序的段表，可以看到一共有33个段。如下图。在ELF被映射时，是以页长度为单位的。如果按照段来映射，那么33个段每个段都要映射到页长的整数倍大小的空间里，这将造成极大的内存空间浪费。
查看段表：

其实，操作系统在映射ELF时，关心的只是段的权限（可读、可写和可执行）。因此，可以将相同权限的段合并在一起来进行映射，从而避免大量因对齐导致的内存空间浪费。合并之后的段被称为“Segment”。如下命令可以查看ELF 的Segment。从下图红框位置，还可以看到每个“Segment” 都合并了哪些段（section）

上述将多个section 合并成segment 的操作是在链接阶段完成的。未链接的.o 目标文件是不存在segment 的，如下

这里可以更仔细的看一下图二中的program header，他们描述了ELF文件应该如何被映射到进程的虚拟空间。比如前两个program header 的type 是LOAD类型。后台运行该程序，查看该程序的虚拟内存maps，如下图。可以发现两个LOAD类型的segment 刚好对应maps 里的两块内存，且segment 的VirAddr 和maps 中的也是基本一致（之所以有所偏差，“是因为linux 装载elf 文件时实现了一种‘Hack’ 的做法”-- 书中原文，没看懂…）。可见在静态链接时，就已经决定了程序中每个符号的虚拟地址。

ps:如果是动态链接的话，program header 中的segment 的虚拟地址就无法直接和maps 中的地址对应起来了，如下：

附录

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{

	while (1) {
		sleep(1000);
	}

	return 0;
}