深入了解linux系统—— 库的链接和加载-LINUX-PHP中文网

一、目标文件

我们知道源文件经过编译链接形成可执行程序，在

Windows

登录后复制

下这两个步骤被

IDEA

登录后复制

封装的很完美，我们使用起来也非常方便；

在

Linux

登录后复制

中，我们可以通过

gcc

登录后复制

编译器来完成编译链接这一系列操作。

而源文件经过编译形成

.o

登录后复制

文件，而库文件是由

.o

登录后复制

文件形成的；那

.o

登录后复制

文件是什么呢？

.o

登录后复制

文件被称为目标文件，也被称为可重定位目标文件；

目标文件是一个二进制文件，其格式是

ELF

登录后复制

二、ELF文件

而我们还知道，我们源文件经过编译形成

.o

登录后复制

文件，然后再经过链接（将所有的

.o

登录后复制

文件合并，链接库文件）才能形成可执行文件。

那在链接的过程中做了什么呢？我们的

.o

登录后复制

文件为什么能够和库文件进行链接呢？

目标文件的文件格式是

ELF

登录后复制

、库文件的文件格式也是

ELF

登录后复制

、可执行文件的文件格式也是

ELF

登录后复制

可以看到

.o

登录后复制

目标文件、共享目标文件、可执行文件的文件格式都是

ELF

登录后复制

。

ELF文件组成

.o

登录后复制

、库文件

.so

登录后复制

（静态库

.a

登录后复制

是

.o

登录后复制

的归档文件）以及可执行文件都是

ELF

登录后复制

格式文件，那

ELF

登录后复制

文件都包含什么呢？

一般

ELF

登录后复制

文件都包含以下几部分：

ELF

登录后复制

头（

ELF Header

登录后复制

）程序头表（

program Header Table

登录后复制

）节（

Section

登录后复制

)节头表（

Section Header Table

登录后复制

）

那这些部分都包含哪些内容呢？

在

Linux

登录后复制

系统中，我们可以通过指令

readelf

登录后复制

来查看

ELF

登录后复制

格式文件的这几个部分的内容。

节（

Section

登录后复制

）

节是

ELF

登录后复制

文件中的基本组成单位，包含了特定类型的数据；

ELF

登录后复制

文件的各种信息和数据都存储在不同的节中。

例如

.text

登录后复制

、

.data

登录后复制

、

.bss

登录后复制

等。

节头表（

Section Header Table

登录后复制

）

在

ELF

登录后复制

文件中存在非常多的节，那如何区分这些节呢？

在节头表

Section Header Table

登录后复制

中，就记录了每一个节的描述信息。（比如

Name

登录后复制

、

Type

登录后复制

、

Address

登录后复制

）

我们可以使用

readelf -S

登录后复制

来查看一个ELF文件的节头表：

这里内容比较多，只截取了一部分；

在这里面，我们可以看到存在

.text

登录后复制

代码、

.data

登录后复制

数据、

rodata

登录后复制

只读数据、

.bss

登录后复制

等。

程序头表

program Header Table

登录后复制

在程序头表中，记录了所有有效段和它们的属性。

在表中记录着每一段的开始位置和位移

offset

登录后复制

、长度；以及这些段如何去合并

我们可以使用

readelf -l

登录后复制

查看ELF文件的程序头表

ELF Header

在

ELF Header

登录后复制

中，记录了文件的主要特性，程序的入口地址、节的个数，大小等等。

readelf -h

登录后复制

可以查看一个ELF文件的

ELF Header

登录后复制

可执行程序的形成

了解了ELF文件的组成，感觉还是云里雾里的；（这里了解ELF文件中有哪几个部分组成，每一个部分大概内容即可）

那

.o

登录后复制

文件，库文件

.so

登录后复制

以及可执行文件都是ELF文件，那我们的可执行程序(文件)如何形成的呢？

这个就比较简单了，因为我们的

.o

登录后复制

文件的格式都是ELF，所以我们所有的

.o

登录后复制

文件形成可执行时，只需要将所有相同的数据节进行合并形成一个大的数据节；也就是形成一个大的ELF格式的文件。

这里简单了解一下，在后续链接和加载内容中详细说明。

ELF可执行文件的加载

我们知道一个ELF文件中存在非常多的

Section

登录后复制

，在加载到内存时，也会进行

Section

登录后复制

的合并，形成

segment

登录后复制

。

合并规则：相同属性，可读/可写/可执行等等。

这样不同的

Section

登录后复制

在加载到内存时，就会合并成

segment

登录后复制

。

而合并方式在形成ELF时就已经确定了，在ELF的程序头表

Paogram Header Table

登录后复制

中我们可以查看。

可以看到我们的

.text

登录后复制

代码段和

.rodata

登录后复制

只读数据段是被合并到一个

segment

登录后复制

的；

.got

登录后复制

、

.data

登录后复制

和

.bss

登录后复制

段这些可读可写的数据是合并到一个

segment

登录后复制

的。

而我们ELF文件中存在那么多节，如果我们不进行合并就发发现在内存中有非常多的块

登录后复制

KB空间中都存在浪费的空间，而合并节形成

segment

登录后复制

就是为了减小页面碎片，提供内存使用率。还用一点就是：将相同权限的节进行合并，这样具有相同属性的节就会形成一个大的

segment

登录后复制

；这样就可以更好的进行内存管理和权限访问控制。三、链接和加载静态链接

首先我们要知道，静态链接本质上就是将我们所有的

.o

登录后复制

文件和静态库文件进行合并，形成可执行；(静态库就是

.o

登录后复制

文件的归档，所以：静态链接本质上就和将所有的

.o

登录后复制

链接起来）

那

.o

登录后复制

文件是如何链接的呢？

现在有存在

code.c

登录后复制

和

fun.c

登录后复制

两份源文件，简单代码：

代码语言：javascript代码运行次数：0运行复制

<pre class="brush:php;toolbar:false;">//code.c#include <stdio.h>void fun();int main(){    fun();printf("code: \n");return 0;}//fun.c#include <stdio.h>void fun(){printf("fun: \n");}

登录后复制

我们知道编译形成的

.o

登录后复制

以及最终形成的可执行程序都是二进制文件，我们可以使用

objdump

登录后复制

对这些二进制文件进行反汇编。

objdump -d

登录后复制

对代码部分进行反汇编。

我们可以发现，在

code.c

登录后复制

和

fun.c

登录后复制

各自经过编译后形成的

.o

登录后复制

文件，经过反汇编，我们发现，在

code.s

登录后复制

中调用

fun

登录后复制

函数时，

cal

登录后复制

调用的函数地址是

登录后复制

，调用

printf

登录后复制

函数的地址也是

登录后复制

；在

fun.s

登录后复制

中

call

登录后复制

调用

printf

登录后复制

的地址也是

登录后复制

。

我们再来对可执行程序进行返汇编查看一下：

可以看到，在可执行程序反汇编形成的文件中，

callq

登录后复制

调用函数时就有了函数的地址。

readelf -S

登录后复制

可以查看ELF文件的符号表

LuckyCola工具库

LuckyCola工具库是您工作学习的智能助手，提供一系列AI驱动的工具，旨在为您的生活带来便利与高效。

查看详情

在链接时，对照符号表，根据表里记录的地址来修正函数的地址。

所以，链接的本质上就是编译之后的所有目标文件连同用到的一些静态库运行时库组合，形成一个独立的可执行文件。

当所有模块组合在一起之后，链接器就会根据我们的

.o

登录后复制

文件或者静态库中的重定位表找到那些被重定位的函数，从而修改它们的地址。

我们链接的过程中就会涉及到对目标文件

.o

登录后复制

的地址修正（地址重定位）；所以

.o

登录后复制

目标文件也被称为可重定位目标文件。

加载ELF和进程地址空间

这里有一个问题：进程地址空间

mm_struct

登录后复制

和

vm_area_struct

登录后复制

在进程刚创建时，初始化数据从哪里来？

我们对

.o

登录后复制

文件、可执行文件进行反汇编可以发现，一个ELF文件，在还没有被加载到内存时，在其内部就存在地址；

上图中最左侧就是ELF文件中的地址；严格意义上将，这种地址应该叫做逻辑地址：起始位置+偏移量。

而当我们把起始位置当做

登录后复制

，此时就成了虚拟地址；也就是说，在我们的程序还没加载到内存时，就已经把可执行程序进行统一编址了。

所以，我们进程在创建时，虚拟地址空间

mm_struct

登录后复制

和

vm_arae_sruct

登录后复制

的初始化数据从哪里来？就显而易见了；

从ELF中的

segment

登录后复制

中来，而每一个

segment

登录后复制

都有自己的起始位置和长度，就用来初始化内核数据结构

vm_area_struct

登录后复制

的

[start , end]

登录后复制

等数据，以及初始化页表。

所以虚拟地址，不仅操作系统要支持，而编译器也要支持。（因为程序在还没有加载到内存时，就已经进行统一编址了）

进程地址空间

所以，在程序运行时，该可执行程序要加载到内存；而进程的进程地址空间

mm_struct

登录后复制

中的虚拟地址从可执行程序中来，而可执行程序的代码和数据要加载到内存；操作系统就要为这些代码和数据开辟空间，然后填充页表。

这样进程才能被

CPU

登录后复制

调度，那

CPU

登录后复制

是如何知道进程的起始地址呢？

还记得在ELF格式的

ELF Header

登录后复制

中，存在一个

Entry point address

登录后复制

入口地址，所以在

CPU

登录后复制

调度进程时，CPU中的

EIP

登录后复制

寄存器，就会记录下一条要运行指令的地址；而在

CPU

登录后复制

在还存在

CR3

登录后复制

寄存器，它指向当前进程的页表。

所以在进程被调度时，就会把

Entry point address

登录后复制

入口地址拷贝到

CPU

登录后复制

中的

EIP

登录后复制

寄存器中，然后再修改CPU中其他信息（如

CR3

登录后复制

等)；这样

CPU

登录后复制

就知道进程的起始地址；而且还知道当前进程的页表，根据进程地址空间中的虚拟地址，查找页表就可以找到当前进程代码和数据的物理地址。

动态库

动态链接，简单来说就是将可执行程序和库产生关联，然后在程序运行时再加载动态库；

这也是我们在动态链接我们自己的库，生成可执行，在运行时还需要让系统找到我们的库的原因。

程序在运行时，才会加载动态库，那进程如何看到我们的动态库呢？

了解了一个进程如何找到我们的动态库；我们还知道动态库也被称为共享目标文件，也就是说我们的库可以被多个进程共享的。

所以在我们进程去找自己依赖的库时，如果当前库已经被加载到内存了，当前进程就可以根据库文件的

struct file

登录后复制

找到库文件的

struct path

登录后复制

，再根据

path

登录后复制

找到

struct dentry

登录后复制

然后就可以找到库文件的

inode

登录后复制

这样就可以找到库文件。

这样讲库映射到进程的地址空间中，这样多个进程就共享同一个库了；而在内存中库文件就只存在一份

动态链接

我们知道静态链接就是将静态库合并到我们的可执行程序中，这样静态链接形成的可执行不依赖库，就可以执行；按理来说应该比的链接更加方便。

但是，当我们静态库文件特别大，我们如果使用静态链接，这样形成的可执行都包含一份静态库代码；而当程序运行起来时，在内存中就势必会存在多份源文件代码。

再看动态链接，只是将可执行文件和动态库文件产生关联，在程序运行时才进行链接，可执行文件中不存在库代码；而且在内存中，多个进程可以共享一个动态库，在内存中也不会出现多份库代码。

那动态链接如何实现的呢？

可执行程序被编译器处理过

在

C/C++

登录后复制

程序开始执行时，它并不是直接执行

main

登录后复制

函数；

实际是程序的入口不是

main

登录后复制

，而是

_start

登录后复制

。

可以看到可执行程序的入口地址并不是

main

登录后复制

、而是

_start

登录后复制

（

Linux

登录后复制

下）；

_start

登录后复制

函数是C运行时库(

glibc

登录后复制

)或者链接器(

id

登录后复制

)提供的特殊函数。

那

_start

登录后复制

函数它做了什么呢？

设置堆栈：为程序创建堆栈环境。初始化数据段：将程序的数据段(全局变量/静态变量)从初始化数据段拷贝到相应的内存位置，清零未初始化的数据段。动态链接：（关键）

_start

登录后复制

函数会调用动态链接器的代码来解析和加载程序所以来的动态库；动态链接器会处理所有符号解析和重定位，确保程序中的函数调用和变量访问能正确映射到动态库中的实际位置。调用

_libc_start_main

登录后复制

：链接完成之后，

_start

登录后复制

函数就会调用

libc_start_main

登录后复制

函数（

glibc

登录后复制

提供的）；

lib_start_main

登录后复制

函数负责执行额外的初始化工作（例如设置信号处理函数，初始化线程库等）；调用

main

登录后复制

函数：

lib_start_main

登录后复制

调用程序的

main

登录后复制

函数，此时程序的执行才到了用户编写的代码；处理

main

登录后复制

返回值：

main

登录后复制

返回时，

lib_start_main

登录后复制

就会处理这个返回值，然后调用

_exit

登录后复制

终止程序。

动态链接器：负责在程序运行时加载动态库

可以看到这里程序都依赖

ld-linux-x86-64.so.2

登录后复制

这一个库。也就是动态链接器库

在程序启动时，动态链接器就会解析程序中的动态库依赖，并将这些库加载到内存中；

Linux

登录后复制

系统通过环境变量（

LD_LIBRARY_PATH

登录后复制

）/配置文件(

etc/ld.so.conf

登录后复制

)来指定动态库的搜索路径；这些路径会被动态链接器在加载动态库时进行搜索。

缓存文件：

为了提高动态库的加载效率，

Linux

登录后复制

系统会维护一个

/etc/ld.so.cache

登录后复制

的缓冲文件；该文件保存了系统中所有已知动态库的路径和相关信息，动态链接器在加载动态库时会优先搜索这个缓冲文件。库函数调用

说了这么多，那动态库该如何链接和加载的呢？我们的程序又是如何调用库函数呢？

那我们就清楚了，库映射到进程地址空间后，我们只需要知道库的起始虚拟地址和要调用方法的偏移量就可以找到库中的方法。

那也就是说，我们在动态链接的过程中，我们只需要记录下来调用库函数依赖的库名称，和该库函数中动态库中的偏移量地址即可。

全局偏移量表

GOT

登录后复制

在动态链接的过程中，在程序中就下来了库函数所依赖的库名称，以及该函数在动态库中的偏移量地址。这样在程序运行时，要进行动态库的加载（如果库在内存中已经存在，就直接映射），这样在程序的地址空间中就存在了动态库的映射；那也就知道了库的起始虚拟地址；这样，我们再对加载到内存中的程序的库函数调用处，修改动态库的地址；在内存中完成二次地址重定位。

但是，我们知道代码区是只读的；那如何修改呢？代码区是不能修改的。