含大量图文解析及例程 | Linux下的ELF文件、链接、加载与库（中）

刘盼

发布于 2022-08-26 15:53:51

2.1K0

发布于 2022-08-26 15:53:51

文章被收录于专栏：人人都是极客人人都是极客

可执行文件的装载

进程和装载的基本概念的介绍

程序（可执行文件）和进程的区别

程序是静态的概念，它就是躺在磁盘里的一个文件。
进程是动态的概念，是动态运行起来的程序。

现代操作系统如何装载可执行文件

给进程分配独立的虚拟地址空间
将可执行文件映射到进程的虚拟地址空间（mmap）
将CPU指令寄存器设置到程序的入口地址，开始执行

可执行文件在装载的过程中实际上如我们所说的那样是映射的虚拟地址空间，所以可执行文件通常被叫做映像文件(或者Image文件)。

可执行ELF文件的两种视角

可执行ELF格式具有不寻常的双重特性，编译器、汇编器和链接器将这个文件看作是被区段（section）头部表描述的一系列逻辑区段的集合，而系统加载器将文件看成是由程序头部表描述的一系列段（segment）的集合。一个段（segment）通常会由多个区段（section）组成。例如，一个“可加载只读”段可以由可执行代码区段、只读数据区段和动态链接器需要的符号区段组成。

区段（section）是从链接器的视角来看ELF文件，对应段表 Section Headers，而段（segment）是从执行的视角来看ELF文件，也就是它会被映射到内存中，对应程序头表 Program Headers。

我们用命令readelf -a [fileName] 中的Section to Segment mapping部分来看一下可执行文件中段的映射关系。

可执行文件的程序头表

我们用readelf -h [fileName]命令查看一个可执行ELF文件的ELF头时，会发现与可重定位ELF文件的ELF头有一个重大不同：可重定位文件ELF头中 Start of program headers 为0，因为它是没有程序头表，Program Headers，Elf64_Phdr的；而在可执行ELF文件中，Start of program headers 是有值的，为64，也就是说，在可执行ELF文件中程序头表会紧接着ELF头（因为ELF头的大小即为64字节）。

我们通过readelf -l [fileName]可以直接查看到程序头表。

可执行ELF文件个进程虚拟地址空间的映射关系

我们可以通过 cat /proc/[pid]/maps 来查看某个进程的虚拟地址空间。

该虚拟文件有6列，分别为：

vdso的全称是虚拟动态共享库（virtual dynamic shared library），而vsyscall的全称是虚拟系统调用（virtual system call），关于这部分内容有兴趣的读者可以看看https://0xax.gitbooks.io/linux-insides/content/SysCall/syscall-3.html。

总体来说，在程序加载过程中，磁盘上的可执行文件，进程的虚拟地址空间，还有机器的物理内存的映射关系如下：

Linux下的装载过程

接下来我们进一步探究一下Linux是怎么识别和装载ELF文件的，我们需要深入Linux内核去寻找答案 (内核实际处理过程涉及更多的过程，我们这里主要关注和ELF文件处理相关的代码)。

当我们在bash下输入命令执行某一个ELF文件的时候，首先bash进程调用fork()系统调用创建一个新的进程，然后新的进程调用execve()系统调用执行指定的ELF文件 ,内核开始真正的装载工作。

下图是Linux内核代码中与ELF文件的装载相关的一些代码：

/fs/binfmt_elf.c中 Load_elf_binary的代码走读：

检查ELF文件头部信息(一致性检查)
加载程序头表(可以看到一个可执行程序必须至少有一个段（segment），而所有段的大小之和不能超过64K(65536u))
寻找和处理解释器段(动态链接部分会介绍)
装入目标程序的段(elf_map)
填写目标程序的入口地址
填写目标程序的参数，环境变量等信息(create_elf_tables)
start_thread会将 eip 和 esp 改成新的地址，就使得CPU在返回用户空间时就进入新的程序入口
…

例子：静态ELF加载器，加载 a.out 执行

我们同样以刚才介绍静态链接时的a.c、b.c、main.c的例子来看一下静态链接的可执行文件的加载。

静态ELF文件的加载：将磁盘上静态链接的可执行文件按照ELF program header，正确地搬运到内存中执行。

操作系统在execve时完成：

操作系统在内核态调用mmap

进程还未准备好时，由内核直接执行 ”系统调用“
映射好 a.out 的代码、数据、堆区、堆栈、vvar、vdso、vsyscall

更简单的实现：直接读入进程的地址空间

加载完成之后，静态链接的程序就开始从ELF entry开始执行，之后就变成我们熟悉的状态机，唯一的行为就是取指执行。

我们通过readelf来查看a.out文件的信息：

readelf -h a.out

输出：

我们这里看到，程序的入口地址是：Entry point address: 0x400a80。我们接着用gdb来调试：

上图是笔者在gdb中调试的一些内容：

我们用starti来使得程序在第一条指令就停下，可以看到，程序确实是从0x400180开始的，与我们上面查到的入口地址一致。
而我们用cat /proc/[PID]/maps 来查看这个程序中内存的内容，看到我们之前提到的代码、数据、堆区、堆栈、vvar、vdso、vsyscall都已经被映射进了内存中。

调试的结果符合我们对静态程序加载时操作系统的行为的预期。

动态链接

什么是动态链接以及为什么需要动态链接

实际上，链接程序在链接时一般是优先链接动态库的，除非我们显式地使用-static参数指定链接静态库，像这样：

gcc -static hello.c

静态链接和动态链接的可执行文件的大小差距还是很显著的，因为静态库被链接后库就直接嵌入可执行文件中了。

这样就带来了两个弊端：

首先就是系统空间被浪费了。这是显而易见的，想象一下，如果多个程序链接了同一个库，则每一个生成的可执行文件就都会有一个库的副本，必然会浪费系统空间。
再者，一旦发现了库中有bug或者是需要升级，必须把链接该库的程序找出来，然后全部需要重新编译。

libc.so中有300K 条指令，2 MiB 大小，每个程序如果都静态链接，浪费的空间很大，最好是整个系统里只有一个 libc 的副本，而每个用到 libc 的程序在运行时都可以用到 libc 中的代码。

下图中的 hello-dy 和 hello-st 是同一个hello源文件hello.c分别动态 / 静态链接后生成的可执行文件的大小，大家可以感受一下，查了一百倍。而且这只是链接了libc标准库，在大型项目中，我们要链接各种各样的第三方库，而静态链接会把全部在链接时就链接到同一个可执行文件，那么其大小是很难接受的。

动态库的出现正是为了弥补静态库的弊端。因为动态库是在程序运行时被链接的，所以磁盘上和内存中只要保留一份副本，因此节约了磁盘空间。如果发现了bug或要升级也很简单，只要用新的库把原来的替换掉就行了。

Linux环境下的动态链接对象都是以.so为扩展名的共享对象(Shared Object)。

真的是动态链接的吗？

我们常说gcc默认的链接类型就是动态链接，而且我们及其中运行的大部分进程也都是动态链接的，真的是这样的吗？我们不妨来做个实验验证一下。

我们通过创建一个动态链接库 libhuge.so，然后创建1000个进程去调用这个库中的foo函数，该函数是128M 个 nop。如果程序不是动态链接的话，1000 * 128MB的内存占用足以撑爆大多数个人电脑的内存。而如果程序确实是动态链接的，即内存中只有一份代码，那么只会有很小的内存占用。我们是这样做的：

首先我们有huge.S：

.global foo
foo:
        # 128MiB of nop
        .fill 1024 * 1024 * 128, 1, 0x90
        ret

这就是我们刚才说的一个动态链接库的源代码。我们一会儿会把他编译成 libhuge.so供我们的huge.c调用，我们的huge.c是这样的：

#include <unistd.h>
#include <stdio.h>
int main(){
 foo(); // huge code, dynamic linked
 printf("pid = %d\n", getpid());
 while (1) sleep(1);
}

它会调用foo函数，并在结束后打印自己的PID，然后睡眠。Makefile如下：

LIB := /tmp/libhuge.so

all: $(LIB) a.out

$(LIB): huge.S
 gcc -fPIC -shared huge.S -o $@

a.out: huge.c $(LIB)
 gcc -o $@ huge.c -L/tmp -lhuge

clean:
 rm -f *.so *.out $(LIB)

正如我们刚才所介绍的，我们会先将huge.S编译成动态链接库libhuge.so放在/tmp下，然后我们的huge.c回去动态链接这个库，并完成自己的代码。这还不够，我们要创建1000个进程来执行上述行为。这样才能验证我们的动态链接是不是在内存中真的只有一份代码，我们用下面的脚本来完成：

#!/bin/bash

# for i in {1...1000}
for i in `seq 1 100`
do
 LD_LIBRARY_PATH=/tmp ./a.out &
done

wait
# ps | grep "a.out" | grep -Po "^(\d)*" | xargs kill -9  用于清空生成的进程

实验证明，我们的操作系统能够很好地运行这1000个进程，并且内存只多占用了 400MB。也就是说，库中的foo函数确实是动态链接的，内存中只有一份foo的副本。

这在操作系统内核不难实现：所有以只读方式映射同一个文件的部分（如代码部分）时，都指向同一个副本，这个过程中会创建引用计数。

动态链接的例子

假如我们要制作一个关于向量的动态链接库libvector.so，它包含两个源代码addvec.c和multvec.c如下：我们只需要这样来进行编译：

gcc -shared -fpic -o libvector.so addvec.c multvec.c

其中-fpic选项告诉编译器生成位置无关代码（PIC），而-shared选项告诉编译器生成共享库。

我们现在拿一个使用到这个共享库的可执行文件来看一下，其源代码main.c：

// main.c
#include<stdio.h>

int addvec(int*, int*, int*, int);

int x[2] = {1, 2};
int y[2] = {3, 4};
int z[2];

int main(){
        addvec(x, y, z, 2);
        printf("z = [%d %d]\n", z[0], z[1]);
        while(1);
        return 0;
}

注意我们在最后加了一个死循环是为了让进程保持运行，然后去查看进程的虚拟地址空间。

我们先编译源码，注意在同目录下可以直接按以下命令编译，之后我们会介绍将动态链接库放到环境目录后的编译命令。

gcc main.c ./libvector.so

然后先用file命令查看生成的可执行文件a.out的文件信息，再用ldd命令查看其需要的动态库，最后查看其虚拟地址空间。

file a.out

输出：

我们看到，该可执行文件是共享对象，并且是动态链接的。

ldd a.out

输出：

ldd命令就是用来查看该文件所依赖的动态链接库。

./a.out & cat /proc/12002/maps

输出：

我们看到，除了像静态链接时，进程地址空间中的堆、栈、vvar、vdso、vsyscall等之外，还有了许多动态链接库.so。

动态链接的实现机制

程序头表

我们同样用readelf -l [fileName]来查看动态链接的可执行ELF文件的程序头表：

readelf -l a.out

可以看到编译完成之后地址是从 0x00000000 开始的，即编译完成之后最终的装载地址是不确定的。

关键技术

之前在静态链接的过程中我们提到过重定位的过程，那个时候其实属于链接时的重定位，现在我们需要装载时的重定位，主要使用了以下关键技术：

PIC位置无关代码
GOT全局偏移表
GOT配合PLT实现的延迟绑定技术

引入动态链接之后，实际上在操作系统开始运行我们的应用程序之前，首先会把控制权交给动态链接器，它完成了动态链接的工作之后再把控制权交给应用程序。

可以看到动态链接器的路径在.interp这个段中体现，并且通常它是个软链接，最终链接在像ld-2.27.so这样的共享库上。

.dynamic段

我们来看一下和动态链接相关的.dynamic段和它的结构，.dynamic段其实就是全局偏移表的第一项，即GOT[0]。

可以通过readelf -d [fileName]来查看。

它对应的是elf.h中的Elf64_Dyn这个结构体。

动态链接器ld

对于动态链接的可执行文件，内核会分析它的动态链接器地址，把动态链接器映射到进程的地址空间，把控制权交给动态链接器。动态链接器本身也是.so文件，但是它比较特殊，它是静态链接的。本身不依赖任何其他的共享对象也不能使用全局和静态变量。这是合理的，试想，如果动态链接器都是动态链接的话，那么由谁来完成它的动态链接呢？