计算机组成原理(4)静态链接与动态链接

如果说同一个cpu支持相同的计算机指令集，那么为什么同一个程序在windows下可以执行，在linux下却不可以呢？这是因为两个操作系统下可执行文件的格式不一样。 Linux 下是 ELF 文件格式，而 Windows 的可执行文件格式是一种叫作 PE的文件格式。Linux 下的装载器只能解析 ELF 格式而不能解析 PE 格式。

编译、链接和装载：拆解程序执行

写好的 C 语言代码，可以通过编译器编译成汇编代码，然后汇编代码再通过汇编器变成 CPU 可以理解的机器码，于是 CPU 就可以执行这些机器码了。这个描述把整个过程大大简化了。实际上，“C 语言代码 - 汇编代码 - 机器码”  这个过程，在我们的计算机上进行的时候是由两部分组成的。

第一个部分由编译（Compile）、汇编（Assemble）以及链接（Link）三个阶段组成。在这三个阶段完成之后，我们就生成了一个可执行文件。

第二部分，我们通过装载器（Loader）把可执行文件装载（Load）到内存中。CPU 从内存中读取指令和数据，来开始真正执行程序。

ELF 格式和链接：理解链接过程 

在 Linux 下，可执行文件和目标文件所使用的都是一种叫 ELF（Execuatable and Linkable File Format）的文件格式，中文名字叫可执行与可链接文件格式，这里面不仅存放了编译成的汇编指令，还保留了很多别的数据。

ELF 文件格式把各种信息，分成一个一个的 Section 保存起来。ELF 有一个基本的文件头（File Header），用来表示这个文件的基本属性，比如是否是可执行文件，对应的 CPU、操作系统等等。除了这些基本属性之外，大部分程序还有这么一些 Section：代码段，数据段，重定位表以及符号表。

重定位表：保留的是当前的文件里面，哪些跳转地址其实是我们不知道的。比如我们在 main 函数里面调用了  printf 这个函数，但是在链接发生之前，我们并不知道该跳转到哪里，这些信息就会存储在重定位表里； 

符号表：保留了我们所说的当前文件里面定义的函数名称和对应地址的地址簿。

当我们有多个目标代码或者调用了静态程序库的时候，链接器会扫描所有输入的目标文件，然后把所有符号表里的信息收集起来，构成一个全局的符号表。然后再根据重定位表，把所有不确定要跳转地址的代码，根据符号表里面存储的地址，进行一次修正。最后，把所有的目标文件的对应段进行一次合并，变成了最终的可执行代码。

在链接器把程序变成可执行文件之后，要装载器去装载程序就容易多了。装载器不再需要考虑地址跳转的问题，只需要解析 ELF 文件，把对应的指令和数据，加载到内存里面供 CPU 执行就可以了。（链接器合并整合代码，装载器加载程序到内存供cpu执行）

我们去写可以用的程序，也不仅仅是把所有代码放在一个文件里来编译执行，而是可以拆分成不同的函数库，最后通过一个静态链接的机制，使得不同的文件之间既有分工，又能通过静态链接来“合作”，变成一个可执行的程序。

 

程序装载面临的挑战

上面说到通过链接器，把多个文件合并成一个最终可执行文件。在运行这些可执行文件的时候，我们其实是通过一个装载器，解析 ELF 或者 PE 格式的可执行文件。装载器会把对应的指令和数据加载到内存里面来，让 CPU 去执行。为了达到这个目的，装载器需要满足两个要求。

第一，可执行程序加载后占用的内存空间应该是连续的。执行指令的时候，程序计数器是顺序地一条一条指令执行下去。这也就意味着，这一条条指令需要连续地存储在一起。

第二，我们需要同时加载很多个程序，并且不能让程序自己规定在内存中加载的位置。虽然编译出来的指令里已经有了对应的各种各样的内存地址，但是实际加载的时候，我们其实没有办法确保，这个程序一定加载在哪一段内存地址上。因为我们现在的计算机通常会同时运行很多个程序，可能你想要的内存地址已经被其他加载了的程序占用了。

要满足这两个基本的要求的一个办法就是内存映射。那就是在内存里面，找到一段连续的内存空间，然后分配给装载的程序，然后把这段连续的内存空间地址，和整个程序指令里指定的内存地址做一个映射。（这里的映射，是程序指令中的虚拟地址与实际内存的物理地址进行映射）指令里用到的内存地址叫作虚拟内存地址（Virtual Memory Address），实际在内存硬件里面的空间地址，我们叫物理内存地址（Physical Memory Address）。

 

内存分页解决内存碎片问题

 我们来看这样一个例子。我现在手头的这台电脑，有 1GB 的内存。我们先启动一个图形渲染程序，占用了 512MB 的内存，接着启动一个 Chrome 浏览器，占用了 128MB 内存，再启动一个 Python 程序，占用了 256MB 内存。这个时候，我们关掉Chrome，于是空闲内存还有 1024 - 512 - 256 = 256MB。按理来说，我们有足够的空间再去装载一个 200MB 的程序。但是，这 256MB 的内存空间不是连续的，而是被分成了两段 128MB 的内存。因此，实际情况是，我们的程序没办法加载进来。这就是内存碎片问题。

出现这种情况时候我们可以采用内存交换来解决 。我们可以先把图中256mb的python程序写入硬盘，再从硬盘重新写入内存，就能补回那128mb的空隙了。这样，我们就有了连续的 256MB 内存空间，就可以去加载一个新的 200MB 的程序。但是，硬盘的访问速度要比内存慢很多，而每一次内存交换，我们都需要把一大段连续的内存数据写到硬盘上。所以，如果内存交换的时候，交换的是一个很占内存空间的程序，这样整个机器都会显得卡顿。

当需要进行内存交换的时候，让需要交换写入或者从磁盘装载的数据更少一点，这样就可以解决这个问题。这个办法，在现在计算机的内存管理里面，就叫作内存分页。和分段这样分配一整段连续的空间给到程序相比，分页是把整个物理内存空间切成一段段固定尺寸的大小。而对应的程序所需要占用的虚拟内存空间，也会同样切成一段段固定尺寸的大小。这样一个连续并且尺寸固定的内存空间，我们叫页（Page）。从虚拟内存到物理内存的映射，不再是拿整段连续的内存的物理地址，而是按照一个一个页来的。页的尺寸一般远远小于整个程序的大小。

实际上，我们的操作系统当要读取特定的页，却发现数据并没有加载到物理内存里的时候，就会触发一个来自于 CPU 的缺页错误（Page Fault）。我们的操作系统会捕捉到这个错误，然后将对应的页，从存放在硬盘上的虚拟内存里读取出来，加载到物理内存里。这种方式，使得我们可以运行那些远大于我们实际物理内存的程序。同时，这样一来，任何程序都不需要一次性加载完所有指令和数据，只需要加载当前需要用到就行了。 

通过引入虚拟内存、页映射和内存交换，我们的程序本身，就不再需要考虑对应的真实的内存地址（系统根据虚拟内存找到物理内存）、程序加载、内存管理（有碎片系统会自动进行内存交换，保证空间利用）等问题了。任何一个程序，都只需要把内存当成是一块完整而连续的空间来直接使用。

动态链接

根据我们上面讲的静态链接（把对应的不同文件内的代码段，合并到一起，成为最后的可执行文件），如果我们两个不同程序都调用了同一个函数库的函数，那么执行两个程序的时内存里就存在两段对应函数代码。如果我们有很多个程序都要通过装载器装载到内存里面，那里面链接好的同样的功能代码，也都需要再装载一遍，再占一遍内存空间。

我们之前说的合并代码段的方法，就是静态链接（Static Link）。在动态链接的过程中，我们想要“链接”的，不是存储在硬盘上的目标文件代码，而是加载到内存中的共享库（Shared Libraries）。顾名思义，这里的共享库重在“共享“这两个字。这个加载到内存中的共享库会被很多个程序的指令调用到。在 Windows 下，这些共享库文件就是.dll 文件，也就是 Dynamic-Link Libary（DLL，动态链接库）。在 Linux 下，这些共享库文件就是.so 文件，也就是 Shared Object（一般我们也称之为动态链接库）。这两大操作系统下的文件名后缀，一个用了“动态链接”的意思，另一个用了“共享”的意思，正好覆盖了两方面的含义。

 

简而言之，动态链接就是把共用的代码事先加载一份在内存里，然后不同程序共同动态调用它就完事了。这里存在一个问题就是，不同程序里虚拟地址不一样，怎么映射到真正的共享代码段呢，cpu是通过维护查找关系表来确定的。每次程序加载的时候，都会事先确定关系代码段物理地址与虚拟地址的相对地址关系。详情请看极客时间《深入浅出计算机原理》第十讲。