参考《深入理解计算机系统》、《深入浅出计算机组成原理》
从高级语言到汇编代码，再到机器码，就是一个日常开发程序，最终变成了CPU可以执行的计算机指令的过程。
常见的指令可以分成五大类：
第一类是算术类指令。我们的加减乘除，在CPU层面，都会变成一条条算术类指令。
第二类是数据传输类指令。给变量赋值、在内存里读写数据，用的都是数据传输类指令。
第三类是逻辑类指令。逻辑上的与或非，都是这一类指令。
第四类是条件分支类指令。日常我们写的“if/else”，其实都是条件分支类指令。
第四类是无条件跳转指令。写一些大一点的程序，我们常常需要写一些函数或者方法。在调用函数的时 候，其实就是发起了一个无条件跳转指令。
示例如下：
MIPS是一组由MIPS公司设计出的CPU指令集。目前整个芯片架构和指令集均开源了。
MIPS的指令是一个32位的整数，高6位叫操作码（Opcode），也就是代表这条指令具体是一条什么样的指令，剩下的26位有三种格式，分别是R、I和J。
R指令是一般用来做算术和逻辑操作，里面有读取和写入数据的寄存器的地址。如果是逻辑位移操作，后面还有位移操作的位移量，而最后的功能码，则是在前面的操作码不够的时候，扩展操作码表示对应的具体指令的。
I指令，则通常是用在数据传输、条件分支，以及在运算的时候使用的并非变量还是常数的时候。这个时候，没有了位移量和功能码，也没有了第三个寄存器，而是把这三部分直接合并成了一个地址值或者一个常数。
J指令就是一个跳转指令，高6位之外的26位都是一个跳转后的地址。 以一个简单的加法算术指令：
add $t0, $s1, $s2
为例来解释。为了方便，我们下面都用十进制来表示对应的代码。
对应的MIPS指令里opcode是0，rs代表第一个寄存器s1的地址是17，rt代表第二个寄存器s2的地址是18，rd代表目标的临时寄存器t0的地址，是8。因为不是位移操作，所以位移量是0。把这些数字拼在一起，就变成了一个MIPS的加法指令。
为了读起来方便，我们一般把对应的二进制数，用16进制表示出来。在这里，也就是0X02324020。这个数字也就是这条指令对应的机器码。
如果我们用打孔代表1，没有打孔代表0，用4行8列代表一条指令来打一个穿孔纸带，那么这条命令大概就长这样：
好了，恭喜你，读到这里，你应该学会了怎么作为人肉编译和汇编器，给纸带打孔编程了，不用再对那些用 过打孔卡的前辈们顶礼膜拜了。
一个CPU里面会有很多种不同功能的寄存器。我这里给你介绍三种比较特殊的。
一个是PC寄存器（Program Counter Register），我们也叫指令地址寄存器（Instruction AddressRegister）。顾名思义，它就是用来存放下一条需要执行的计算机指令的内存地址。
第二个是指令寄存器（Instruction Register），用来存放当前正在执行的指令。
第三个是条件码寄存器（Status Register），用里面的一个一个标记位（Flag），存放CPU进行算术或者逻 辑计算的结果。
除了这些特殊的寄存器，CPU里面还有更多用来存储数据和内存地址的寄存器。这样的寄存器通常一类里面不止一个。我们通常根据存放的数据内容来给它们取名字，比如整数寄存器、浮点数寄存器、向量寄存器和地址寄存器等等。有些寄存器既可以存放数据，又能存放地址，我们就叫它通用寄存器。
实际上，一个程序执行的时候，CPU会根据PC寄存器里的地址，从内存里面把需要执行的指令读取到指令寄存器里面执行，然后根据指令长度自增，开始顺序读取下一条指令。可以看到，一个程序的一条条指令，在内存里面是连续保存的，也会一条条顺序加载。
而有些特殊指令，比如J类指令，也就是跳转指令，会修改PC寄存器里面的地址值。这样，下一条要执行的指令就不是从内存里面顺序加载的了。事实上，这些跳转指令的存在，也是我们可以在写程序的时候，使用if…else条件语句和while/for循环语句的原因。
举个例子
#include <time.h>
#include <stdlib.h>
int main()
{
srand(time(NULL));
int r = rand() % 2;
int a = 10;
if(r==0){
a = 1;
} else {
a = 2;
}
}编译
$ gcc -g -c test.c
$ objdump -d -S test.o 得到
可以看到，这里对于r == 0的条件判断，被编译成了cmp和jne这两条指令。
cmp指令比较了前后两个操作数的值，这里的DWORD PTR代表操作的数据类型是32位的整数，而**[rbp-0x4]**则是一个寄存器的地址。所以，第一个操作数就是从寄存器里拿到的变量r的值。
第二个操作数0x0就是我们设定的常量0的16进制表示。cmp指令的比较结果，会存入到条件码寄存器当中去。
在这里，如果比较的结果是False，也就是0，就把零标志条件码（对应的条件码是ZF，Zero Flag）设置为1。除了零标志之外，Intel的CPU下还有进位标志（CF，Carry Flag）、符号标志（SF，Sign Flag）以及溢出标志（OF，Overflow Flag），用在不同的判断条件下。
cmp指令执行完成之后，PC寄存器会自动自增，开始执行下一条jne的指令。
跟着的jne指令，是jump if not equal的意思，它会查看对应的零标志位。如果为0，会跳转到后面跟着的操作数4a的位置。这个4a，对应这里汇编代码的行号，也就是上面设置的else条件里的第一条指令。当跳转发生的时候，PC寄存器就不再是自增变成下一条指令的地址，而是被直接设置成这里的4a这个地址。
这个时候，CPU再把4a地址里的指令加载到指令寄存器中来执行。跳转到执行地址为4a的指令，实际是一条mov指令，第一个操作数和前面的cmp指令一样，是另一个32位整型的寄存器地址，以及对应的2的16进制值0x2。mov指令把2设置到对应的寄存器里去，相当于一个赋值操作。
然后，PC寄存器里的值继续自增，执行下一条mov指令。这条mov指令的第一个操作数eax，代表累加寄存器，第二个操作数0x0则是16进制的0的表示。这条指令其实没有实际的作用，它的作用是一个占位符。
我们回过头去看前面的if条件，如果满足的话，在赋值的mov指令执行完成之后，有一个jmp的无条件跳转指令。跳转的地址就是这一行的地址51。因为我们的if…else之后整个main函数就结束了，所以if指令执行完成之后没有合适的指令可以跳转，于是编译器自动生成了这样一条废指令，使得if…else条件里的内容结束之后，都能跳转到这同一个位置。
如果通过mac来编译这段小程序，会稍有不同，不过原理类似，在这里贴出mac平台编译后的结果：
test.o: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 _main:
; {
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 48 83 ec 10 subq $16, %rsp
8: 31 c0 xorl %eax, %eax
a: 89 c7 movl %eax, %edi
c: c7 45 fc 00 00 00 00 movl $0, -4(%rbp)
; srand(time(NULL));
13: e8 00 00 00 00 callq 0 <_main+0x18>
18: 89 c7 movl %eax, %edi
1a: e8 00 00 00 00 callq 0 <_main+0x1f>
; int r = rand() % 2;
1f: e8 00 00 00 00 callq 0 <_main+0x24>
24: 99 cltd
25: b9 02 00 00 00 movl $2, %ecx
2a: f7 f9 idivl %ecx
2c: 89 55 f8 movl %edx, -8(%rbp)
; int a = 10;
2f: c7 45 f4 0a 00 00 00 movl $10, -12(%rbp)
; if (r == 0)
36: 83 7d f8 00 cmpl $0, -8(%rbp)
3a: 0f 85 0c 00 00 00 jne 12 <_main+0x4c>
; a = 1;
40: c7 45 f4 01 00 00 00 movl $1, -12(%rbp)
; } else {
47: e9 07 00 00 00 jmp 7 <_main+0x53>
; a = 2;
4c: c7 45 f4 02 00 00 00 movl $2, -12(%rbp)
; }
53: 8b 45 fc movl -4(%rbp), %eax
56: 48 83 c4 10 addq $16, %rsp
5a: 5d popq %rbp
5b: c3 retq哈哈，原来if ... else就是goto操作。其利用jne指令而已。
首先，我们来定义一个函数：
#include <stdio.h>
int static add(int a, int b)
{
return a+b;
}
int main()
{
int x = 5;
int y = 10;
int u = add(x, y);
}个程序定义了一个简单的函数add，接受两个参数a和b，返回值就是a+b。而main函数里则定义了两个变量x和y，然后通过调用这个add函数，来计算u=x+y，最后把u的数值打印出来。
我们把这个程序编译之后，objdump出来。我们来看一看对应的汇编代码。
可以看出来，在这段代码里，main函数和上面我们讲的的程序执行区别并不大，它主要是把jump指令换成了函数调用的call指令。call指令后面跟着的，仍然是跳转后的程序地址。
这些你理解起来应该不成问题。我们下面来看一个有意思的部分。
我们来看add函数。可以看到，add函数编译之后，代码先执行了一条push指令和一条mov指令；在函数执行结束的时候，又执行了一条pop和一条ret指令。这四条指令的执行，其实就是在进行我们接下来要讲压栈（Push）和出栈（Pop）操作。
你有没有发现，函数调用和上一节我们讲的if…else和for/while循环有点像。它们两个都是在原来顺序执行的指令过程里，执行了一个内存地址的跳转指令，让指令从原来顺序执行的过程里跳开，从新的跳转后的位置开始执行。
那我们有没有一个可以不跳转回到原来开始的地方，来实现函数的调用呢？直觉上似乎有这么一个解决办法。你可以把调用的函数指令，直接插入在调用函数的地方，替换掉对应的call指令，然后在编译器编译代码的时候，直接就把函数调用变成对应的指令替换掉。
不过，仔细琢磨一下，你会发现这个方法有些问题。如果函数A调用了函数B，然后函数B再调用函数A，我们就得面临在A里面插入B的指令，然后在B里面插入A的指令，这样就会产生无穷无尽地替换。就好像两面镜子面对面放在一块儿，任何一面镜子里面都会看到无穷多面镜子。
看来，把被调用函数的指令直接插入在调用处的方法行不通。那我们就换一个思路，能不能把后面要跳回来 执行的指令地址给记录下来呢？就像前面讲PC寄存器一样，我们可以专门设立一个“程序调用寄存器”， 来存储接下来要跳转回来执行的指令地址。等到函数调用结束，从这个寄存器里取出地址，再跳转到这个记 录的地址，继续执行就好了。
但是在多层函数调用里，简单只记录一个地址也是不够的。我们在调用函数A之后，A还可以调用函数B，B还能调用函数C。这一层又一层的调用并没有数量上的限制。在所有函数调用返回之前，每一次调用的返回地址都要记录下来，但是我们CPU里的寄存器数量并不多。像我们一般使用的Intel i7 CPU只有16个64位寄存器，调用的层数一多就存不下了。
最终，计算机科学家们想到了一个比单独记录跳转回来的地址更完善的办法。我们在内存里面开辟一段空间，用栈这个后进先出（LIFO，Last In First Out）的数据结构。栈就像一个乒乓球桶，每次程序调用函数之前，我们都把调用返回后的地址写在一个乒乓球上，然后塞进这个球桶。这个操作其实就是我们常说的压栈。如果函数执行完了，我们就从球桶里取出最上面的那个乒乓球，很显然，这就是出栈。
拿到出栈的乒乓球，找到上面的地址，把程序跳转过去，就返回到了函数调用后的下一条指令了。如果函数A在执行完成之前又调用了函数B，那么在取出乒乓球之前，我们需要往球桶里塞一个乒乓球。而我们从球桶最上面拿乒乓球的时候，拿的也一定是最近一次的，也就是最下面一层的函数调用完成后的地址。乒乓球桶的底部，就是栈底，最上面的乒乓球所在的位置，就是栈顶。
在真实的程序里，压栈的不只有函数调用完成后的返回地址。比如函数A在调用B的时候，需要传输一些参数数据，这些参数数据在寄存器不够用的时候也会被压入栈中。整个函数A所占用的所有内存空间，就是函数A的栈帧（Stack Frame）。Frame在中文里也有“相框”的意思，所以，每次到这里，我都有种感觉，整个函数A所需要的内存空间就像是被这么一个“相框”给框了起来，放在了栈里面。
而实际的程序栈布局，顶和底与我们的乒乓球桶相比是倒过来的。底在最上面，顶在最下面，这样的布局是因为栈底的内存地址是在一开始就固定的。而一层层压栈之后，栈顶的内存地址是在逐渐变小而不是变大。
对应上面函数add的汇编代码，我们来仔细看看，main函数调用add函数时，add函数入口在0～1行，add函数结束之后在12～13行。 add函数的第0行，push rbp这个指令，就是在进行压栈。这里的rbp又叫栈帧指针（Frame Pointer），是一个存放了当前栈帧位置的寄存器。push rbp就把之前调用函数的返回地址，压到栈顶。接着，第1行的一条命令mov rbp, rsp里，则是把rsp这个栈指针（Stack Pointer）的值复制到rbp里，而rsp始终会指向栈顶。这个命令意味着，rbp这个栈帧指针指向的返回地址，变成当前最新的栈顶，也就是add函数的返回地址了。
而在函数add执行完成之后，又会分别调用第12行的pop rbp来将当前的栈顶出栈，然后调用第13行的ret指令，将程序的控制权返回到出栈后的栈顶，也就是main函数的返回地址。
上面我们提到一个方法，把一个实际调用的函数产生的指令，直接插入到的位置，来替换对应的函数调用指令。尽管这个通用的函数调用方案，被我们否决了，但是如果被调用的函数里，没有调用其他函数，这个方法还是可以行得通的。
事实上，这就是一个常见的编译器进行自动优化的场景，我们通常叫函数内联（Inline）。我们只要在GCC编译的时候，加上对应的一个让编译器自动优化的参数-O，编译器就会在可行的情况下，进行这样的指令替换。
我们来看一段代码。
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
int static add(int a, int b)
{
return a+b;
}
int main()
{
srand(time(NULL));
int x = rand() % 5
int y = rand() % 10;
int u = add(x, y)
printf("u = %d\n", u)
}为了避免编译器优化掉太多代码，我小小修改了一下function_example.c，让参数x和y都变成了，通过随机数生成，并在代码的最后加上将u通过printf打印出来的语句。
通过打印汇编代码，没有把add函数单独编译成一段指令顺序，而是在调用u = add(x, y)的时候，直接替换成了一个add指令。
return a+b;
4c: 01 de add esi,ebx除了依靠编译器的自动优化，你还可以在定义函数的地方，加上inline的关键字，来提示编译器对函数进行内联。
内联带来的优化是，CPU需要执行的指令数变少了，根据地址跳转的过程不需要了，压栈和出栈的过程也不用了。
不过内联并不是没有代价，内联意味着，我们把可以复用的程序指令在调用它的地方完全展开了。如果一个函数在很多地方都被调用了，那么就会展开很多次，整个程序占用的空间就会变大了。
这样没有调用其他函数，只会被调用的函数，我们一般称之为叶子函数（或叶子过程）。
我们首先思考一个问题，为什么程序无法同时在Linux和Windows平台运行?
既然我们的程序最终都被变成了一条条机器码去执行，那为什么同一个程序，在同一台计算机上，在Linux下可以运行，而在Windows下却不行呢？反过来，Windows上的程序在Linux上也是一样不能执行的。可是我们的CPU并没有换掉，它应该可以识别同样的指令呀？
写好的C语言代码，可以通过编译器编译成汇编代码，然后汇编代码再通过汇编器变成CPU可以理解的机器码，于是CPU就可以执行这些机器码了。你现在对这个过程应该不陌生了，但是这个描述把过程大大简化了。下面，我们一起具体来看，C语言程序是如何变成一个可执行程序的。
我们首先写两个c文件如下：
#add_lib.c
int add(int a, int b){
return a + b;
}#link_example.c
#include <stdio.h>
int main()
{
int a = 10;
int b = 5;
int c = add(a, b);
printf("c=%d\n", c);
}我们通过gcc来编译这两个文件，然后通过objdump命令看看它们的汇编代码。
$ gcc -g -c add_lib.c link_example.c
$ objdump -d -S add_lib.o
$ objdump -d -S link_example.oadd_lib.o: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 _add:
; int add(int a, int b){
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 89 7d fc movl %edi, -4(%rbp)
7: 89 75 f8 movl %esi, -8(%rbp)
; return a + b;
a: 8b 45 fc movl -4(%rbp), %eax
d: 03 45 f8 addl -8(%rbp), %eax
10: 5d popq %rbp
11: c3 retqlink_example.o: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 _main:
; {
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 48 83 ec 10 subq $16, %rsp
; int a = 10;
8: c7 45 fc 0a 00 00 00 movl $10, -4(%rbp)
; int b = 5;
f: c7 45 f8 05 00 00 00 movl $5, -8(%rbp)
; int c = add(a, b);
16: 8b 7d fc movl -4(%rbp), %edi
19: 8b 75 f8 movl -8(%rbp), %esi
1c: b0 00 movb $0, %al
1e: e8 00 00 00 00 callq 0 <_main+0x23>
23: 89 45 f4 movl %eax, -12(%rbp)
; printf("c=%d\n", c);
26: 8b 75 f4 movl -12(%rbp), %esi
29: 48 8d 3d 14 00 00 00 leaq 20(%rip), %rdi
30: b0 00 movb $0, %al
32: e8 00 00 00 00 callq 0 <_main+0x37>
37: 31 c9 xorl %ecx, %ecx
39: 89 45 f0 movl %eax, -16(%rbp)
; }
3c: 89 c8 movl %ecx, %eax
3e: 48 83 c4 10 addq $16, %rsp
42: 5d popq %rbp
43: c3 retq既然代码已经被我们“编译”成了指令，我们不妨尝试运行一下 ./link_example.o。
不幸的是，文件没有执行权限，我们遇到一个Permission denied错误。即使通过chmod命令赋予link_example.o文件可执行的权限，运行./link_example.o仍然只会得到一条cannot execute binary file: Exec format error的错误。
我们再仔细看一下objdump出来的两个文件的代码，会发现两个程序的地址都是从0开始的。如果地址是一样的，程序如果需要通过call指令调用函数的话，它怎么知道应该跳转到哪一个文件里呢？
这么说吧，无论是这里的运行报错，还是objdump出来的汇编代码里面的重复地址，都是因为 add_lib.o 以及 link_example.o并不是一个可执行文件（Executable Program），而是目标文件（Object File）。只有通过链接器（Linker）把多个目标文件以及调用的各种函数库链接起来，我们才能得到一个可执行文件。
我们通过gcc的-o参数，可以生成对应的可执行文件，对应执行之后，就可以得到这个简单的加法调用函数的结果。
$ gcc -o link-example add_lib.o link_example.o
$ ./link_example
c = 15实际上，“C语言代码-汇编代码-机器码” 这个过程，在我们的计算机上进行的时候是由两部分组成的。
第一个部分由编译（Compile）、汇编（Assemble）以及链接（Link）三个阶段组成。在这三个阶段完成之后，我们就生成了一个可执行文件。
第二部分，我们通过装载器（Loader）把可执行文件装载（Load）到内存中。CPU从内存中读取指令和数据，来开始真正执行程序。
程序最终是通过装载器变成指令和数据的，所以其实我们生成的可执行代码也并不仅仅是一条条的指令。我们还是通过objdump指令，把可执行文件的内容拿出来看看。
link_example: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000100000f20 _add:
100000f20: 55 pushq %rbp
100000f21: 48 89 e5 movq %rsp, %rbp
100000f24: 89 7d fc movl %edi, -4(%rbp)
100000f27: 89 75 f8 movl %esi, -8(%rbp)
100000f2a: 8b 45 fc movl -4(%rbp), %eax
100000f2d: 03 45 f8 addl -8(%rbp), %eax
100000f30: 5d popq %rbp
100000f31: c3 retq
100000f32: 90 nop
100000f33: 90 nop
100000f34: 90 nop
100000f35: 90 nop
100000f36: 90 nop
100000f37: 90 nop
100000f38: 90 nop
100000f39: 90 nop
100000f3a: 90 nop
100000f3b: 90 nop
100000f3c: 90 nop
100000f3d: 90 nop
100000f3e: 90 nop
100000f3f: 90 nop
0000000100000f40 _main:
100000f40: 55 pushq %rbp
100000f41: 48 89 e5 movq %rsp, %rbp
100000f44: 48 83 ec 10 subq $16, %rsp
100000f48: c7 45 fc 0a 00 00 00 movl $10, -4(%rbp)
100000f4f: c7 45 f8 05 00 00 00 movl $5, -8(%rbp)
100000f56: 8b 7d fc movl -4(%rbp), %edi
100000f59: 8b 75 f8 movl -8(%rbp), %esi
100000f5c: b0 00 movb $0, %al
100000f5e: e8 bd ff ff ff callq -67 <_add>
100000f63: 89 45 f4 movl %eax, -12(%rbp)
100000f66: 8b 75 f4 movl -12(%rbp), %esi
100000f69: 48 8d 3d 36 00 00 00 leaq 54(%rip), %rdi
100000f70: b0 00 movb $0, %al
100000f72: e8 0d 00 00 00 callq 13 <link_example.c+0x100000f84>
100000f77: 31 c9 xorl %ecx, %ecx
100000f79: 89 45 f0 movl %eax, -16(%rbp)
100000f7c: 89 c8 movl %ecx, %eax
100000f7e: 48 83 c4 10 addq $16, %rsp
100000f82: 5d popq %rbp
100000f83: c3 retq
Disassembly of section __TEXT,__stubs:
0000000100000f84 __stubs:
100000f84: ff 25 76 10 00 00 jmpq *4214(%rip)你会发现，可执行代码dump出来内容，和之前的目标代码长得差不多，但是长了很多。因为在Linux下，可执行文件和目标文件所使用的都是一种叫ELF（Execuatable and Linkable File Format）的文件格式，中文名字叫可执行与可链接文件格式，这里面不仅存放了编译成的汇编指令，还保留了很多别的数据。
比如我们过去所有objdump出来的代码里，你都可以看到对应的函数名称，像add、main等等，乃至你自己定义的全局可以访问的变量名称，都存放在这个ELF格式文件里。这些名字和它们对应的地址，在ELF文件里面，存储在一个叫作符号表（Symbols Table）的位置里。符号表相当于一个地址簿，把名字和地址关联了起来。
我们先只关注和我们的add以及main函数相关的部分。你会发现，这里面，main函数里调用add的跳转地址，不再是下一条指令的地址了，而是add函数的入口地址了，这就是EFL格式和链接器的功劳。
ELF文件格式把各种信息，分成一个一个的Section保存起来。ELF有一个基本的文件头（File Header），用来表示这个文件的基本属性，比如是否是可执行文件，对应的CPU、操作系统等等。除了这些基本属性之外，大部分程序还有这么一些Section：
- 首先是.text Section，也叫作代码段或者指令段（Code Section），用来保存程序的代码和指令；
- 接着是.data Section，也叫作数据段（Data Section），用来保存程序里面设置好的初始化数据信息；
- 然后就是.rel.text Secion，叫作重定位表（Relocation Table）。重定位表里，保留的是当前的文件里面，哪些跳转地址其实是我们不知道的。比如上面的 link_example.o 里面，我们在main函数里面调用了 add 和 printf 这两个函数，但是在链接发生之前，我们并不知道该跳转到哪里，这些信息就会存储在重定位表里；
- 最后是.symtab Section，叫作符号表（Symbol Table）。符号表保留了我们所说的当前文件里面定义的函数名称和对应地址的地址簿。
链接器会扫描所有输入的目标文件，然后把所有符号表里的信息收集起来，构成一个全局的符号表。然后再根据重定位表，把所有不确定要跳转地址的代码，根据符号表里面存储的地址，进行一次修正。最后，把所有的目标文件的对应段进行一次合并，变成了最终的可执行代码。这也是为什么，可执行文件里面的函数调用的地址都是正确的。
在链接器把程序变成可执行文件之后，要装载器去执行程序就容易多了。装载器不再需要考虑地址跳转的问题，只需要解析 ELF 文件，把对应的指令和数据，加载到内存里面供CPU执行就可以了。
讲到这里，相信你已经猜到，为什么同样一个程序，在Linux下可以执行而在Windows下不能执行了。其中一个非常重要的原因就是，两个操作系统下可执行文件的格式不一样。
我们今天讲的是Linux下的ELF文件格式，而Windows的可执行文件格式是一种叫作PE（Portable Executable Format）的文件格式。Linux下的装载器只能解析ELF格式而不能解析PE格式。
如果我们有一个可以能够解析PE格式的装载器，我们就有可能在Linux下运行Windows程序了。这样的程序真的存在吗？没错，Linux下著名的开源项目Wine，就是通过兼容PE格式的装载器，使得我们能直接在Linux下运行Windows程序的。而现在微软的Windows里面也提供了WSL，也就是Windows Subsystem for Linux，可以解析和加载ELF格式的文件。
我们去写可以用的程序，也不仅仅是把所有代码放在一个文件里来编译执行，而是可以拆分成不同的函数库，最后通过一个静态链接的机制，使得不同的文件之间既有分工，又能通过静态链接来“合作”，变成一个可执行的程序。
对于ELF格式的文件，为了能够实现这样一个静态链接的机制，里面不只是简单罗列了程序所需要执行的指令，还会包括链接所需要的重定位表和符号表。
上一讲，我们看到了如何通过链接器，把多个文件合并成一个最终可执行文件。在运行这些可执行文件的时候，我们其实是通过一个装载器，解析ELF或者PE格式的可执行文件。装载器会把对应的指令和数据加载到内存里面来，让CPU去执行。
说起来只是装载到内存里面这一句话的事儿，实际上装载器需要满足两个要求。
第一，可执行程序加载后占用的内存空间应该是连续的。执行指令的时候，程序计数器是顺序地一条一条指令执行下去。这也就意味着，这一条条指令需要连续地存储在一起。
**第二，我们需要同时加载很多个程序，并且不能让程序自己规定在内存中加载的位置。**虽然编译出来的指令里已经有了对应的各种各样的内存地址，但是实际加载的时候，我们其实没有办法确保，这个程序一定加载在哪一段内存地址上。因为我们现在的计算机通常会同时运行很多个程序，可能你想要的内存地址已经被其他加载了的程序占用了。
要满足这两个基本的要求，我们很容易想到一个办法。那就是我们可以在内存里面，找到一段连续的内存空间，然后分配给装载的程序，然后把这段连续的内存空间地址，和整个程序指令里指定的内存地址做一个映射。
我们把指令里用到的内存地址叫作虚拟内存地址（Virtual Memory Address），实际在内存硬件里面的空间地址，我们叫物理内存地址（Physical Memory Address）。
程序里有指令和各种内存地址，我们只需要关心虚拟内存地址就行了。对于任何一个程序来说，它看到的都是同样的内存地址。我们维护一个虚拟内存到物理内存的映射表，这样实际程序指令执行的时候，会通过虚拟内存地址，找到对应的物理内存地址，然后执行。因为是连续的内存地址空间，所以我们只需要维护映射关系的起始地址和对应的空间大小就可以了。
这种找出一段连续的物理内存和虚拟内存地址进行映射的方法，我们叫分段（Segmentation）**。**这里的段，就是指系统分配出来的那个连续的内存空间。
分段的办法很好，解决了程序本身不需要关心具体的物理内存地址的问题，但它也有一些不足之处，第一个就是内存碎片（Memory Fragmentation）的问题。
我们来看这样一个例子。我现在手头的这台电脑，有1GB的内存。我们先启动一个图形渲染程序，占用了512MB的内存，接着启动一个Chrome浏览器，占用了128MB内存，再启动一个Python程序，占用了256MB内存。这个时候，我们关掉Chrome，于是空闲内存还有1024 - 512 - 256 = 256MB。按理来说，我们有足够的空间再去装载一个200MB的程序。但是，这256MB的内存空间不是连续的，而是被分成了两段128MB的内存。因此，实际情况是，我们的程序没办法加载进来。
当然，这个我们也有办法解决。解决的办法叫内存交换（Memory Swapping）。
我们可以把Python程序占用的那256MB内存写到硬盘上，然后再从硬盘上读回来到内存里面。不过读回来的时候，我们不再把它加载到原来的位置，而是紧紧跟在那已经被占用了的512MB内存后面。这样，我们就有了连续的256MB内存空间，就可以去加载一个新的200MB的程序。如果你自己安装过Linux操作系统，你应该遇到过分配一个swap硬盘分区的问题。这块分出来的磁盘空间，其实就是专门给Linux操作系统进行内存交换用的。
虚拟内存、分段，再加上内存交换，看起来似乎已经解决了计算机同时装载运行很多个程序的问题。不过，你千万不要大意，这三者的组合仍然会遇到一个性能瓶颈。硬盘的访问速度要比内存慢很多，而每一次内存交换，我们都需要把一大段连续的内存数据写到硬盘上。所以，如果内存交换的时候，交换的是一个很占内存空间的程序，这样整个机器都会显得卡顿。
既然问题出在内存碎片和内存交换的空间太大上，那么解决问题的办法就是，少出现一些内存碎片。另外，当需要进行内存交换的时候，让需要交换写入或者从磁盘装载的数据更少一点，这样就可以解决这个问题。这个办法，在现在计算机的内存管理里面，就叫作内存分页（Paging）。
和分段这样分配一整段连续的空间给到程序相比，分页是把整个物理内存空间切成一段段固定尺寸的大小。而对应的程序所需要占用的虚拟内存空间，也会同样切成一段段固定尺寸的大小。这样一个连续并且尺寸固定的内存空间，我们叫页（Page）。从虚拟内存到物理内存的映射，不再是拿整段连续的内存的物理地址，而是按照一个一个页来的。页的尺寸一般远远小于整个程序的大小。在Linux下，我们通常只设置成4KB。你可以通过命令看看你手头的Linux系统设置的页的大小。
$ getconf PAGE_SIZE由于内存空间都是预先划分好的，也就没有了不能使用的碎片，而只有被释放出来的很多4KB的页。即使内存空间不够，需要让现有的、正在运行的其他程序，通过内存交换释放出一些内存的页出来，一次性写入磁盘的也只有少数的一个页或者几个页，不会花太多时间，让整个机器被内存交换的过程给卡住。
更进一步地，分页的方式使得我们在加载程序的时候，不再需要一次性都把程序加载到物理内存中。我们完全可以在进行虚拟内存和物理内存的页之间的映射之后，并不真的把页加载到物理内存里，而是只在程序运行中，需要用到对应虚拟内存页里面的指令和数据时，再加载到物理内存里面去。
实际上，我们的操作系统，的确是这么做的。当要读取特定的页，却发现数据并没有加载到物理内存里的时候，就会触发一个来自于CPU的缺页错误（Page Fault）。我们的操作系统会捕捉到这个错误，然后将对应的页，从存放在硬盘上的虚拟内存里读取出来，加载到物理内存里。这种方式，使得我们可以运行那些远大于我们实际物理内存的程序。同时，这样一来，任何程序都不需要一次性加载完所有指令和数据，只需要加载当前需要用到就行了。
通过虚拟内存、内存交换和内存分页这三个技术的组合，我们最终得到了一个让程序不需要考虑实际的物理内存地址、大小和当前分配空间的解决方案。这些技术和方法，对于我们程序的编写、编译和链接过程都是透明的。这也是我们在计算机的软硬件开发中常用的一种方法，就是加入一个间接层。
通过引入虚拟内存、页映射和内存交换，我们的程序本身，就不再需要考虑对应的真实的内存地址、程序加载、内存管理等问题了。任何一个程序，都只需要把内存当成是一块完整而连续的空间来直接使用。
程序的链接，是把对应的不同文件内的代码段，合并到一起，成为最后的可执行文件。这个链接的方式，让我们在写代码的时候做到了“复用”。同样的功能代码只要写一次，然后提供给很多不同的程序进行链接就行了。
这么说来，“链接”其实有点儿像我们日常生活中的标准化、模块化生产。我们有一个可以生产标准螺帽的生产线，就可以生产很多个不同的螺帽。只要需要螺帽，我们都可以通过链接的方式，去复制一个出来，放到需要的地方去，大到汽车，小到信箱。
但是，如果我们有很多个程序都要通过装载器装载到内存里面，那里面链接好的同样的功能代码，也都需要再装载一遍，再占一遍内存空间。这就好比，假设每个人都有骑自行车的需要，那我们给每个人都生产一辆自行车带在身边，固然大家都有自行车用了，但是马路上肯定会特别拥挤。
我们上一节解决程序装载到内存的时候，讲了很多方法。说起来，最根本的问题其实就是内存空间不够用。如果我们能够让同样功能的代码，在不同的程序里面，不需要各占一份内存空间，那该有多好啊！就好比，现在马路上的共享单车，我们并不需要给每个人都造一辆自行车，只要马路上有这些单车，谁需要的时候，直接通过手机扫码，都可以解锁骑行。
这个思路就引入一种新的链接方法，叫作动态链接（Dynamic Link）。相应的，我们之前说的合并代码段的方法，就是静态链接（Static Link）。
在动态链接的过程中，我们想要“链接”的，不是存储在硬盘上的目标文件代码，而是加载到内存中的共享库（Shared Libraries）。顾名思义，这里的共享库重在“共享“这两个字。
这个加载到内存中的共享库会被很多个程序的指令调用到。在Windows下，这些共享库文件就是.dll文件，也就是Dynamic-Link Libary（DLL，动态链接库）。在Linux下，这些共享库文件就是.so文件，也就是Shared Object（一般我们也称之为动态链接库）。这两大操作系统下的文件名后缀，一个用了“动态链接”的意思，另一个用了“共享”的意思，正好覆盖了两方面的含义。
不过，要想要在程序运行的时候共享代码，也有一定的要求，就是这些机器码必须是“地址无关”的。也就是说，我们编译出来的共享库文件的指令代码，是地址无关码（Position-Independent Code）。换句话说就是，这段代码，无论加载在哪个内存地址，都能够正常执行。如果不是这样的代码，就是地址相关的代码。
如果还不明白，我给你举一个生活中的例子。如果我们有一个骑自行车的程序，要“前进500米，左转进入天安门广场，再前进500米”。它在500米之后要到天安门广场了，这就是地址相关的。如果程序是“前进500米，左转，再前进500米”，无论你在哪里都可以骑车走这1000米，没有具体地点的限制，这就是地址无关的。
你可以想想，大部分函数库其实都可以做到地址无关，因为它们都接受特定的输入，进行确定的操作，然后给出返回结果就好了。无论是实现一个向量加法，还是实现一个打印的函数，这些代码逻辑和输入的数据在内存里面的位置并不重要。
而常见的地址相关的代码，比如绝对地址代码（Absolute Code）、利用重定位表的代码等等，都是地址相关的代码。你回想一下我们之前讲过的重定位表。在程序链接的时候，我们就把函数调用后要跳转访问的地址确定下来了，这意味着，如果这个函数加载到一个不同的内存地址，跳转就会失败。
对于所有动态链接共享库的程序来讲，虽然我们的共享库用的都是同一段物理内存地址，但是在不同的应用程序里，它所在的虚拟内存地址是不同的。我们没办法、也不应该要求动态链接同一个共享库的不同程序，必须把这个共享库所使用的虚拟内存地址变成一致。如果这样的话，我们写的程序就必须明确地知道内部的内存地址分配。
那么问题来了，我们要怎么样才能做到，动态共享库编译出来的代码指令，都是地址无关码呢？
动态代码库内部的变量和函数调用都很容易解决，我们只需要使用相对地址（Relative Address）就好了。各种指令中使用到的内存地址，给出的不是一个绝对的地址空间，而是一个相对于当前指令偏移量的内存地址。因为整个共享库是放在一段连续的虚拟内存地址中的，无论装载到哪一段地址，不同指令之间的相对地址都是不变的。
要实现动态链接共享库，也并不困难，和前面的静态链接里的符号表和重定向表类似，还是和前面一样，我们还是拿出一小段代码来看一看。
首先，lib.h 定义了动态链接库的一个函数 show_me_the_money。
// lib.h
#ifndef LIB_H
#define LIB_H
void show_me_the_money(int money);
#endiflib.c包含了lib.h的实际实现。
// lib.c
#include <stdio.h>
void show_me_the_money(int money)
{
printf("Show me USD %d from lib.c \n", money);
}然后，show_me_poor.c 调用了 lib 里面的函数。
// show_me_poor.c
#include "lib.h"
int main()
{
int money = 5;
show_me_the_money(money);
}最后，我们把 lib.c 编译成了一个动态链接库，也就是 .so 文件。
$ gcc lib.c -fPIC -shared -o lib.so
$ gcc -o show_me_poor show_me_poor.c ./lib.so你可以看到，在编译的过程中，我们指定了一个 -fPIC 的参数。这个参数其实就是Position Independent Code的意思，也就是我们要把这个编译成一个地址无关代码。
然后，我们再通过gcc编译show_me_poor 动态链接了lib.so的可执行文件。在这些操作都完成了之后，我们把show_me_poor这个文件通过objdump出来看一下。
$ objdump -d -S show_me_poor
……
0000000000400540 <show_me_the_money@plt-0x10>:
400540: ff 35 12 05 20 00 push QWORD PTR [rip+0x200512] # 600a58 <_GLOBAL_OFFSET_TABLE_+0x8>
400546: ff 25 14 05 20 00 jmp QWORD PTR [rip+0x200514] # 600a60 <_GLOBAL_OFFSET_TABLE_+0x10>
40054c: 0f 1f 40 00 nop DWORD PTR [rax+0x0]
0000000000400550 <show_me_the_money@plt>:
400550: ff 25 12 05 20 00 jmp QWORD PTR [rip+0x200512] # 600a68 <_GLOBAL_OFFSET_TABLE_+0x18>
400556: 68 00 00 00 00 push 0x0
40055b: e9 e0 ff ff ff jmp 400540 <_init+0x28>
……
0000000000400676 <main>:
400676: 55 push rbp
400677: 48 89 e5 mov rbp,rsp
40067a: 48 83 ec 10 sub rsp,0x10
40067e: c7 45 fc 05 00 00 00 mov DWORD PTR [rbp-0x4],0x5
400685: 8b 45 fc mov eax,DWORD PTR [rbp-0x4]
400688: 89 c7 mov edi,eax
40068a: e8 c1 fe ff ff call 400550 <show_me_the_money@plt>
40068f: c9 leave
400690: c3 ret
400691: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0]
400698: 00 00 00
40069b: 0f 1f 44 00 00 nop DWORD PTR [rax+rax*1+0x0]
……我们还是只关心整个可执行文件中的一小部分内容。你应该可以看到，在main函数调用show_me_the_money的函数的时候，对应的代码是这样的：
call 400550 <show_me_the_money@plt>
这里后面有一个@plt的关键字，代表了我们需要从PLT，也就是程序链接表（Procedure Link Table）里面找要调用的函数。对应的地址呢，则是400550这个地址。
那当我们把目光挪到上面的 400550 这个地址，你又会看到里面进行了一次跳转，这个跳转指定的跳转地址，你可以在后面的注释里面可以看到，GLOBAL_OFFSET_TABLE+0x18。这里的GLOBAL_OFFSET_TABLE，就是我接下来要说的全局偏移表。
400550: ff 25 12 05 20 00 jmp QWORD PTR [rip+0x200512] # 600a68 <_GLOBAL_OFFSET_TABLE_+0x18>
在动态链接对应的共享库，我们在共享库的data section里面，保存了一张全局偏移表（GOT，Global Offset Table）。**虽然共享库的代码部分的物理内存是共享的，但是数据部分是各个动态链接它的应用程序里面各加载一份的。**所有需要引用当前共享库外部的地址的指令，都会查询GOT，来找到当前运行程序的虚拟内存里的对应位置。而GOT表里的数据，则是在我们加载一个个共享库的时候写进去的。
不同的进程，调用同样的lib.so，各自GOT里面指向最终加载的动态链接库里面的虚拟内存地址是不同的。
这样，虽然不同的程序调用的同样的动态库，各自的内存地址是独立的，调用的又都是同一个动态库，但是不需要去修改动态库里面的代码所使用的地址，而是各个程序各自维护好自己的GOT，能够找到对应的动态库就好了。
我们的GOT表位于共享库自己的数据段里。GOT表在内存里和对应的代码段位置之间的偏移量，始终是确定的。这样，我们的共享库就是地址无关的代码，对应的各个程序只需要在物理内存里面加载同一份代码。而我们又要通过各个可执行程序在加载时，生成的各不相同的GOT表，来找到它需要调用到的外部变量和函数的地址。
这是一个典型的、不修改代码，而是通过修改“地址数据”来进行关联的办法。它有点像我们在C语言里面用函数指针来调用对应的函数，并不是通过预先已经确定好的函数名称来调用，而是利用当时它在内存里面的动态地址来调用。