💪 今日博客励志语录：
“人生没有白走的路，你踩过的荆棘、蹚过的泥泞，都会在某一刻，变成你脚下的风。”
★★★ 本文前置知识：
动静态库详解
那么在上一篇文章中，我详解了动静态库是什么以及如何制作我们自己的第三方的动静态库，那么制作完成之后，又用什么样的指令让链接器找到我们自己制作的动静态将其链接，而今天这篇文章的主要内容则是围绕底层，而其中动静态库的链接其中就要涉及到文件的ELF格式，那么文件的ELF格式很多讲Linux操作系统的博主其实很少提及这个东西，但是我认为学习它是很有必要的，了解它的结构不仅能够理解清楚本篇博客所讲的动静态链接是如何做到的，并且理解了ELF格式，我们还能打破语言与系统之间的一层隔阂，那么废话不多说，让我们进入正文的学习
ELF格式是什么
那么很多人或许听说过或者压根就没听说这个专有名词，也就是ELF，那么ELF它究竟是个什么呢？
那么ELF其实没有你想象的那么邪乎或者高大尚，那么首先给它下一个定义，那么ELF就是Linux以及unix下的一个文件的格式
那么什么是所谓的格式呢，那么举一个例子，就好比在大学期间你老师要求你要给他上交一份实验报告，然后你爽快的答应了，接着立马就写完了实验报告然后上交给你的老师，但是不幸的是，你老师只是瞟了一眼你的实验报告，都没有仔细阅读你实验报告的内容，那么就将实验报告给你打回来了，那么你很疑惑的去找你的老师去询问原因，那么你的老师只是轻描淡写的回复一句：“你的实验报告的格式都不对，你的内容没按照我上课要求的结构来写，拿回去重新写。”然后你接着回去问同学才知道，老师要求的一个内容的格式是什么的，也就是第一栏是实验结果，第二栏是实验过程，第三栏是实验心得，那么得按照这个布局写，那么你最终修改你的实验报告之后，上交给老师终于顺利过关
那么刚才就是想通过这个例子告诉读者，那么所谓的ELF其实就是一种规定文件内容的格式或者说布局，就像刚才的例子一样，那么你的实验报告的内容必须按照你老师的要求来划分来布局，同理这里的ELF格式就规定Linux下的文件的内容应该按照怎么样的格式或者结构来布局
现在知道了ELF的概念之后，那么ELF的格式究竟长什么样子呢，那么它规定文件是按照这样的格式来划分或者说布局：
那么它将文件的内容分成了四个部分，那么每一个部分都有各自的作用，那么他们分别是：
elf头程序头表段节头表
那么想必你肯定对它们的作用以及构成感到陌生，那么没有关系，你先记住ELF规定下的文件的构成的这四个部分，而所有的可执行文件就好比学生，那么他可能对自己的实验报告有各种各样的想法与创意，那么无论他有多么的想要在自己的实验报告上施展才华，但是还是不得不遵守老师的要求，必须按照这个格式来写，那么ELF格式就像一个法规一样约束着文件，那么之所以这么规定，那么肯定有它的好处的
而其中应用ELF文件格式的文件类型则是三种，分别是可重定位文件以及可执行文件以及动态库文件，也就意味着只有这三个类型的文件的内容是必须按照ELF格式来组织的
那么我们可以在Linux上输入readelf指令来查看可执行文件的ELF格式
现在我有一个已经编译链接好的test.exe可执行文件：
//查看ELF程序头表
readelf -l test.exe
//查看ELF头
readelf -h test.exe
//查看ELF节头表
readelf -S test.exe
如何形成ELF格式
那么我们知道应用ELF格式的文件类型只有三种，分别是可执行文件以及动态库文件以及可重定位文件，那么可执行文件以及动态库文件我们知道是什么，而对于可重定位文件，我们可能会感到有点陌生，那么可重定位文件究竟是什么？
我们知道要形成可执行文件需要源文件经过编译以及链接这两个过程才能形成最终的可执行文件，那么所谓的可重定位文件其实就是源文件只编译不链接形成的一系列的.o文件，但是至于为什么称呼它为可重定位文件我在下文会解释说明
也就是说应用ELF格式的文件类型分别是目标文件以及可执行文件以及动态库文件，而可执行文件的生成则是需要源文件经过编译以及链接这两个阶段，那么也就意味着ELF格式一定是在编译的某个阶段生成的，那么也就需要在我们再来完善之前对于生成可执行文化的编译以及链接的过程的理解。
结合ELF来重新完善理解编译与链接全过程
那么生成可执行文件首先需要依赖源文件以及保存函数声明的头文件，那么其中会经历编译以及链接这两个阶段，而其中编译又分为预处理以及语法语义分析以及编译和汇编这四个子过程，那么我们结合ELF格式来完善编译与链接的全过程：
那么首先预处理阶段会进行头文件展开的工作，那么此时源文件会将源文件中#include XXX.h语句给替换为引用的头文件中的内容，那么编译器会逐字逐句拷贝头文件的内容将其复制拷贝到引用该头文件的源文件中，此时还会经历宏替换以及注释消去等工作，那么此时经过预处理阶段会生成后缀名为.i的中间临时文件，而此时由于头文件的内容已经全部拷贝复制到源文件中，那么头文件就不在参与后续的流程了，那么此时预处理阶段后的生成的临时文件的内容还是c/c++代码
经过预处理阶段紧接着就是语法以及语义分析了，那么这个过程的核心内容可以简单理解检查代码中是否有语法错误，其中会构建一棵语法树来进行分析，那么在这个阶段还会收集一些符号信息，比如解析全局变量以及局部变量的声明来确定他们在符号表中对应的符号
接着是编译，那么编译阶段会将之前的.i的中间临时文件的代码由汇编器给转换为汇编码
最后则是汇编，那么在这个阶段就会生成ELF格式的雏形，为什么说是雏形呢，是因为ELF格式是要求包含ELF头以及程序头表以及段以及节头表，而这里的目标.o文件则是没有对应的程序头表，而程序头表则是在链接阶段生成，所以说是雏形。
并且此阶段还会生成一个局部的符号表，由于编译器是以一个文件作为独立的编译单元来进行编译的，也就是说编译器只能看到编译的该文件的内容而看不到其他文件的内容，那么如果该文件只有函数的声明而没有函数的定义，那么此时该函数对应的符号表中的条目就会被标记为未定义，那么会在链接阶段进行处理，而如果该文件中有对应函数的定义，那么此时就会在符号表中填入定义对应的一个逻辑地址，由于生成该.o文件将实际的文件内容进行了分类也就是函数的定义部分被划分进了代码段.text，而其中的全局变量被划分进了数据段.data，那么此时符号表中记录的对应的函数的定义的地址是在该文件中在相对于代码段的起始位置的相对偏移量，所以这里是逻辑地址而不是所谓的虚拟地址 ，更不是物理地址，因为此时还在链接阶段，都没形成可执行文件，更不存在加载到内存分配物理地址，一定要注意区分
所以上文我们埋了一个伏笔，也就是为什么叫目标文件为可重定位文件，就是因为此时符号表记录的是各个符号是逻辑地址而不是虚拟地址，而之前我们Linux进程部分就提到过，CPU到时候运行的指令，接收到的都是虚拟地址，所以必定要将这其中的符号表中的逻辑地址以及翻译成指令的代码段部分中涉及到的逻辑地址的内容给全部转换为虚拟地址，那么这个工作就叫重定位，其中我们链接器肯定得知道代码的哪些部分使用了逻辑地址，比如调用函数就必然会涉及到逻辑地址，那么此时文件内部就会维护一个可重定位表，那么这个表我们就可以简单理解为帮组链接器寻找到代码中哪些位置使用了逻辑地址从而将其重定位转换为虚拟地址，
那么这就是为什么叫目标文件为重定位文件的原因，但是重定位这个工作不是在编译阶段完成的，而是在链接阶段完成的
那么此时的源文件在编译阶段形成了.o文件，那么此时进入链接阶段，那么链接阶段会获取每一个.o文件的局部符号表然后生成一个全局的符号表，那么其中就会合并每一个局部符号表中相同的符号来作为为全局符号表中的一个条目，然后为其分配一个唯一的逻辑地址，那么有的符号有定义，而有的符号没有定义，那么此时链接器会先去各个.o文件中的局部符号表中查找是否有对应的符号的定义，如果有就填入，而如果发现多个文件的局部符号表都有该函数的定义，那么则会报一个重定义的错误，而如果此时链接器没有在所有的.o文件中找到该函数的定义的话，那么此时链接器如果手上持有静态库文件的话，那么接下来它会去静态库中寻找，而静态库的本质就是一系列.o文件的集合，那么它查询的方式和之前是类似的，也就是去这些.o文件中的局部符号表中寻找，那么一旦找到，那么此时就填入进该符号的地址，并且将其对应的函数的定义给拷贝过来，那么如果说静态库还没有找到，那么此时链接器只能将认为该函数的定义可能在动态库中，但是该链接器无法看到动态库中的函数的定义，而只有在该程序运行时，由动态链接器来完成，那么此时会将该符号标记为动态链接，并将其记录整合进动态符号表中
所以这里链接器填入符号表中的定义的地址优先级是先确定可执行文件依赖的.o文件中是否有定义，那么有则直接将其填入，不需要到静态库以及动态库中寻找，如果没有，那么假设该链接器持有静态库文件的话，那么则会到静态库libxxx.a文件中的一系列.o文件中去搜索是否有对应的定义，并且如果假设该静态库中的不同的.o文件均包含该函数的定义，那么则是按照链接器搜索的顺序来引用其中第一个寻找到的.o文件的定义在将其复制拷贝到可执行文件中，最后如果.o文件以及静态库文件都没有,那么编译器只能将其视为动态库中的函数，将其尝试动态链接
那么此时完善好全局的符号表之后，下一步的工作便是重定位，那么要将逻辑地址转换为虚拟地址，而由于此时链接器将多个.o文件给合成一个可执行文件，其中就包括将各个文件相同的节比如.text以及.data给合并，那么此时就要调整每一个符号的逻辑地址，那么逻辑地址是段内便宜，那么最终重定位调整之后，那么符号定义的地址便是段偏移+段内偏移,那么该结果就是虚拟地址
比如func函数是在其.text段，那么合并所有.o文件的.text段之后，那么此时.text段基地址假设为0x112233
而func在合并段内的偏移量为假设为0x223355,那么重定位后func的逻辑地址便是0x112233+0x223355
那么重定位以及合并相同节之后，那么此时就能够生成程序头表了，那么程序头表是知道操作系统如何在内存中加载段，那么其中程序头表中的每一个条目就包含段的类型以及对应的虚拟地址以及物理地址以及读写权限等等
程序头表的形态
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000400040 0x0000000000400040 0x0001c0 0x0001c0 R 0x8
INTERP 0x000200 0x0000000000400200 0x0000000000400200 0x00001c 0x00001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x010000 0x010000 R E 0x200000
LOAD 0x010000 0x0000000000600000 0x0000000000600000 0x002000 0x002000 RW 0x200000
DYNAMIC 0x011000 0x0000000000611000 0x0000000000611000 0x0001d0 0x0001d0 RW 0x8
NOTE 0x00021c 0x000000000040021c 0x000000000040021c 0x000020 0x000020 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
GNU_RELRO 0x011000 0x0000000000611000 0x0000000000611000 0x0001d0 0x0001d0 R 0x1
那么此时生成的可执行文件就按照标准的ELF格式所构成。
所以现在我们便能理解ELF的形成过程，以及它布局的那四个部分的内容了：
elf头：记录该文件的配置信息以及整体的结构信息，其中就包括文件类型以及文件的程序头表的地址以及段表的地址以及段表的数量以及每一个条目的大小，还有程序入口点enter point程序头表：指导操作系统如何加载段到内存，其中包含段的虚拟地址以及物理地址以及权限等段：存储实际内容，包含合并每一个.o文件的.text段以及.data段节头表：记录每一个所有的节的类型以及它的逻辑地址，用来调试
结合ELF完善进程的创建
那么由于可执行文件是最初被存放在磁盘中的，那么创建进程，那么首先就要将磁盘中存放的可执行文件给加载到内存中，那么我们知道Linux下可执行文件是按照ELF格式构成的，那么首先操作系统会读取该文件的ELF头，来获取程序的入口，然后存放到CPU的指令寄存器当中，然后接着操作系统会读取程序头表，那么程序头表记录了该程序的段的信息其中就包括虚拟地址
而我们知道操作系统在将可执行文件中的数据加载到内存的同时会在内核中创建给进程对应的task_struct结构体，那么task_struct结构体就是记录了该进程的地址空间以及对应的页表，而页表中记录了各个页为单位的数据的虚拟地址到物理地址的映射，那么操作系统会根据程序头表来完善创建出页表，那么其中页表中的虚拟地址不一定遵循程序头表中的虚拟地址，因为程序头表只是给操作系统加载内存的建议，那么虚拟地址具体怎么分配还是由操作系自己决定，那么创建出页表之后，以后虚拟到物理的转换就交给页表来完成而不需要程序头表了
那么当我们该进程被调度的时候，那么CPU就会从指令寄存器来依次读取指令，那么其中指令分为操作码与操作数，那么其中的操作数可能是一个数据或者是调用函数的地址，比如读取的指令是call 0x112233，那么call后面的操作数就是地址，而CPU此时读取的所有的指令中涉及到的地址都是虚拟地址，那么此时就需要根据页表转换为实际的物理内存地址来获取目标数据
结语
那么这就是本篇文章全部的内容，那么本篇文章也是博主尽可能尽全力的用通俗易懂的语言来讲解ELF格式，那么这篇文章就是我对ELF格式的一个全部理解与思考了，那么我看csdn上讲解ELF格式的博主并不多，并且讲ELF格式的博主中的内容又太过于结论化以及专业化了，上来就给你抛出ELF格式有啥，怎么用就结束了，那么之所以做这期博客的原因，就是觉得学习ELF格式，能加深对CPU的执行程序以及在Linux下你用c或者c++写的源文件最终形成可执行程序的一个形态与过程的理解，那么能够打通语言与系统方向的一些隔阂，这也是我写这篇博客的初衷，当然涉及到ELF格式相关的内容以及细节确实太多了，那么本文确实叙述不完，那么读者可以下去自己查阅了解，那么如果本文有帮组到你的话，那么还请三连加关注哦，你的支持就是我创作的最大动力！
