编译、链接和装载:拆解程序执行
示例程序:
// 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 -M intel -S add_lib.o
add_lib.o: 文件格式 elf64-x86-64
Disassembly of section .text:
0000000000000000 <add>:
int add(int a, int b){
0: 55 push rbp
1: 48 89 e5 mov rbp,rsp
4: 89 7d fc mov DWORD PTR [rbp-0x4],edi
7: 89 75 f8 mov DWORD PTR [rbp-0x8],esi
return a + b;
a: 8b 45 f8 mov eax,DWORD PTR [rbp-0x8]
d: 8b 55 fc mov edx,DWORD PTR [rbp-0x4]
10: 01 d0 add eax,edx
}
12: 5d pop rbp
13: c3 ret
$ objdump -d -M intel -S link_example.o
link_example.o: 文件格式 elf64-x86-64
Disassembly of section .text:
0000000000000000 <main>:
#include <stdio.h>
int main()
{
0: 55 push rbp
1: 48 89 e5 mov rbp,rsp
4: 48 83 ec 10 sub rsp,0x10
int a = 10;
8: c7 45 fc 0a 00 00 00 mov DWORD PTR [rbp-0x4],0xa
int b = 5;
f: c7 45 f8 05 00 00 00 mov DWORD PTR [rbp-0x8],0x5
int c = add(a, b);
16: 8b 55 f8 mov edx,DWORD PTR [rbp-0x8]
19: 8b 45 fc mov eax,DWORD PTR [rbp-0x4]
1c: 89 d6 mov esi,edx
1e: 89 c7 mov edi,eax
20: b8 00 00 00 00 mov eax,0x0
25: e8 00 00 00 00 call 2a <main+0x2a>
2a: 89 45 f4 mov DWORD PTR [rbp-0xc],eax
printf("c = %d\n", c);
2d: 8b 45 f4 mov eax,DWORD PTR [rbp-0xc]
30: 89 c6 mov esi,eax
32: bf 00 00 00 00 mov edi,0x0
37: b8 00 00 00 00 mov eax,0x0
3c: e8 00 00 00 00 call 41 <main+0x41>
}
41: c9 leave
42: c3 ret
我们来运行一下这个文件:
$ ./link_example.o
bash: ./link_example.o: 权限不够
$ chmod 777 link_example.o
$ ./link_example.o
bash: ./link_example.o: 无法执行二进制文件
我们再仔细看一下objdump出来的两个文件的代码,会发现两个程序的地址都是从0开始的。如果地址是一样的,程序如果需要通过call指令调用函数的话,它怎么知道应该调到哪一个文件里呢?
这么说吧,无论是这里的运行报错,还是objdump出现的汇编代码里面的重复地址,都是因为add_lib.o以及link_example.o并不是一个可执行文件,而是目标文件。只有通过链接器把多个目标文件以及调用的各种函数库链接起来,我们才能得到一个可执行文件。
我们通过gcc的-o参数,可以生成对应的可执行文件,对应执行之后,就可以得到这个简单的加法调用函数的结果。
$ gcc -o link-example add_lib.o link_example.o
$ ./link_example
c = 15
实际上,C语言代码-汇编代码-机器码这个过程,在我们的计算机上进行的时候是由两部分组成:
- 第一部分由编译、汇编、链接三个阶段组成。在这三个阶段完成之后,我们就生成了一个可执行文件
- 第二部分,我们通过装载器(loader)把可执行文件装载(load)到内存中。CPU从内存中读取指令和数据,来开始真正执行程序。
ELF格式和链接:理解链接过程
程序最终是通过装载器变成指令和数据的,所以其实我们生成的可执行代码也并不仅仅是一条条指令。我们还是通过 objdump 指令,把可执行文件的内容拿出来看看。
$ objdump -d -M intel -S link_example
link_example: 文件格式 elf64-x86-64
Disassembly of section .init:
...
Disassembly of section .plt:
...
Disassembly of section .plt.got:
...
Disassembly of section .text:
...
6b0: 55 push rbp
6b1: 48 89 e5 mov rbp,rsp
000000000040051d <add>:
int add(int a, int b){
40051d: 55 push rbp
40051e: 48 89 e5 mov rbp,rsp
400521: 89 7d fc mov DWORD PTR [rbp-0x4],edi
400524: 89 75 f8 mov DWORD PTR [rbp-0x8],esi
return a + b;
400527: 8b 45 f8 mov eax,DWORD PTR [rbp-0x8]
40052a: 8b 55 fc mov edx,DWORD PTR [rbp-0x4]
40052d: 01 d0 add eax,edx
}
40052f: 5d pop rbp
400530: c3 ret
0000000000400531 <main>:
#include <stdio.h>
int main()
{
400531: 55 push rbp
400532: 48 89 e5 mov rbp,rsp
400535: 48 83 ec 10 sub rsp,0x10
int a = 10;
400539: c7 45 fc 0a 00 00 00 mov DWORD PTR [rbp-0x4],0xa
int b = 5;
400540: c7 45 f8 05 00 00 00 mov DWORD PTR [rbp-0x8],0x5
int c = add(a, b);
400547: 8b 55 f8 mov edx,DWORD PTR [rbp-0x8]
40054a: 8b 45 fc mov eax,DWORD PTR [rbp-0x4]
40054d: 89 d6 mov esi,edx
40054f: 89 c7 mov edi,eax
你会发现,可执行代码dump出来内容,和之前的目标代码长的差不多,但是长了很多。因为在Linux下,可执行文件和目标文件所用的都是一种叫做ELF(Execuatable and Linkable File Format)的文件格式,中文名字叫做可执行与可链接文件格式,这里面不仅存放了编译成的汇编指令,还保留了很多别的数据。
比如我们过去所有objdump出来的代码里,可以看到所有对应的函数名称,像add、main,以及全局变量等,都存放在这个ELF格式文件里。这些名字和它们对应的地址,在ELF文件里面,存储在一个叫做符号表(symblos table)的位置里。符号表相当于一个地址薄,把名字和地址关联了起来。
比如,main函数里调用add的跳转地址,不再是下一条指令的地址了,而是add函数的入口地址。这就是EFL格式和链接器的功能。
ELF文件格式把各种信息,分成一个一个的Section保存起来。ELF有一个基本的文件头(File Header),用来表示这个文件的基本属性,比如是否是可执行文件,对应的CPU、操作系统等等。除了这些基本属性之外,大部分程序还有这么一些Section。
.text Section
,也叫做代码段或者指令段(code section),用来保存程序的代码和指令.data Section
,也就是数据段(Data Section),用来保存程序里面已经设置号的初始化数据信息.rel.text Section
,叫做重定位表(Relocation Section)。重定向表,保留的是当前的文件里面,哪些跳转地址其实是我们不知道的。比如上面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程序。
Wiindows下的WSL,也就是 Windows Subsystem for Linux,可以解析和加载ELF格式的文件。
关于静态链接机制
我们写的程序通常会拆分成一个个不同的函数库,最后通过一个静态链接的机制,使得不同的文件之间既有分工,又能通过静态链接来合作,变成一个可执行的程序。
对于ELF格式的文件,为了能够实现这样一个静态链接的机制,里面不只是简单的罗列了程序所需执行的指令,还会包括链接所需要的重定向表和符号表