Quelle est la signification originale des liens dynamiques et des liens statiques sous Linux ?

Anciennes règles, posons d'abord quelques questions :

• Pourquoi des liens dynamiques ?
• Comment faire des liens dynamiques ?
• Qu’est-ce que la technologie de code indépendante de l’adresse ?
• Qu’est-ce que la technologie de liaison retardée ?
• Comment créer des liens explicites pendant l'exécution du programme ?

Pourquoi les liens dynamiques ?

L'émergence des liens dynamiques vise à résoudre certains défauts des liens statiques :

1. Économisez de la mémoire et de l'espace disque : comme le montre la figure ci-dessous,

Program1 et Program2 contiennent respectivement deux modules, Program1.o et Program2.o, et ils nécessitent tous deux le module Lib.o. Dans le cas d'une liaison statique, les deux fichiers cibles utilisent le module Lib.o, ils ont donc des copies dans les fichiers exécutables Program1 et program2 générés par le lien en même temps. Lorsqu'ils sont exécutés en même temps, Lib.o a deux copies. sur le disque et dans la mémoire, lorsqu'il existe un grand nombre de programmes multiples similaires à Lib.o partageant des fichiers cibles dans le système, beaucoup d'espace sera gaspillé.

1. Les liaisons statiques sont très peu conviviales pour le déploiement et la publication des mises à jour du programme

Si un module dépend de 20 modules, lorsqu'un des 20 modules doit être mis à jour, tous les modules doivent être trouvés et recompilés dans un programme exécutable avant que la mise à jour puisse réussir. Chaque fois qu'un module est mis à jour, l'utilisateur le fait. est nécessaire pour obtenir à nouveau un programme très volumineux. Si le programme utilise des liens statiques, il sera très gênant de mettre à jour le programme via le réseau. Une fois qu'il y aura un petit changement quelque part dans le programme, l'intégralité du programme sera re-téléchargée. .

Afin de résoudre les défauts de la liaison statique, la liaison dynamique est introduite. La distribution de la mémoire de la liaison dynamique est comme indiqué dans la figure

Plusieurs programmes s'appuient sur le même fichier objet partagé. Il n'y a qu'une seule copie de ce fichier objet partagé sur le disque et la mémoire, et aucune copie ne sera générée pour faire simple, il ne relie pas les fichiers objets qui le composent. le programme, comme la liaison statique, est effectué uniquement lorsque le programme est en cours d'exécution et le processus de liaison est reporté jusqu'à l'exécution. La méthode de liaison dynamique rend chaque module plus indépendant et moins couplé pendant le processus de développement, ce qui permet aux différents développeurs et organisations de développement de développer et de tester plus facilement de manière indépendante.

Comment effectuer des liens dynamiques ?

Regardez le code suivant :

// lib.c #include void func(int i) { printf("func %d \n", i); } // Program.c void func(int i); int main() { func(1); return 0; }

Le processus de compilation et d'exécution est le suivant :

$ gcc -fPIC -shared -o lib.so lib.c $ gcc -o test Program.c ./lib.so $ ./test $ func 1

Vous pouvez générer une bibliothèque de liens dynamiques via -fPIC et -shared, puis la lier au programme exécutable pour qu'il s'exécute normalement.

Vous pouvez afficher les informations sur les segments de la bibliothèque de liens dynamiques via la commande readelf :

~/test$ readelf -l lib.so Elf file type is DYN (Shared object file) Entry point 0x530 There are 7 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00000000000006e4 0x00000000000006e4 R E 0x200000 LOAD 0x0000000000000e10 0x0000000000200e10 0x0000000000200e10 0x0000000000000218 0x0000000000000220 RW 0x200000 DYNAMIC 0x0000000000000e20 0x0000000000200e20 0x0000000000200e20 0x00000000000001c0 0x00000000000001c0 RW 0x8 NOTE 0x00000000000001c8 0x00000000000001c8 0x00000000000001c8 0x0000000000000024 0x0000000000000024 R 0x4 GNU_EH_FRAME 0x0000000000000644 0x0000000000000644 0x0000000000000644 0x0000000000000024 0x0000000000000024 R 0x4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 GNU_RELRO 0x0000000000000e10 0x0000000000200e10 0x0000000000200e10 0x00000000000001f0 0x00000000000001f0 R 0x1 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame 01 .init_array .fini_array .dynamic .got .got.plt .data .bss 02 .dynamic 03 .note.gnu.build-id 04 .eh_frame_hdr 05 06 .init_array .fini_array .dynamic .got

Vous pouvez voir que l'adresse de chargement du module de lien dynamique commence à 0. 0 est une adresse invalide. Son adresse de chargement sera déterminée lors de l'exécution du programme et est incertaine au moment de la compilation.

Changer le programme :

// Program.c #include void func(int i); int main() { func(1); sleep(-1); return 0; }

Courez pour lire les informations des cartes :

~/test$ ./test & [1] 126 ~/test$ func 1 cat /proc/126/maps 7ff2c59f0000-7ff2c5bd7000 r-xp 00000000 00:00 516391 /lib/x86_64-linux-gnu/libc-2.27.so 7ff2c5bd7000-7ff2c5be0000 ---p 001e7000 00:00 516391 /lib/x86_64-linux-gnu/libc-2.27.so 7ff2c5be0000-7ff2c5dd7000 ---p 000001f0 00:00 516391 /lib/x86_64-linux-gnu/libc-2.27.so 7ff2c5dd7000-7ff2c5ddb000 r--p 001e7000 00:00 516391 /lib/x86_64-linux-gnu/libc-2.27.so 7ff2c5ddb000-7ff2c5ddd000 rw-p 001eb000 00:00 516391 /lib/x86_64-linux-gnu/libc-2.27.so 7ff2c5ddd000-7ff2c5de1000 rw-p 00000000 00:00 0 7ff2c5df0000-7ff2c5df1000 r-xp 00000000 00:00 189022 /mnt/d/wzq/wzq/util/test/lib.so 7ff2c5df1000-7ff2c5df2000 ---p 00001000 00:00 189022 /mnt/d/wzq/wzq/util/test/lib.so 7ff2c5df2000-7ff2c5ff0000 ---p 00000002 00:00 189022 /mnt/d/wzq/wzq/util/test/lib.so 7ff2c5ff0000-7ff2c5ff1000 r--p 00000000 00:00 189022 /mnt/d/wzq/wzq/util/test/lib.so 7ff2c5ff1000-7ff2c5ff2000 rw-p 00001000 00:00 189022 /mnt/d/wzq/wzq/util/test/lib.so 7ff2c6000000-7ff2c6026000 r-xp 00000000 00:00 516353 /lib/x86_64-linux-gnu/ld-2.27.so 7ff2c6026000-7ff2c6027000 r-xp 00026000 00:00 516353 /lib/x86_64-linux-gnu/ld-2.27.so 7ff2c6227000-7ff2c6228000 r--p 00027000 00:00 516353 /lib/x86_64-linux-gnu/ld-2.27.so 7ff2c6228000-7ff2c6229000 rw-p 00028000 00:00 516353 /lib/x86_64-linux-gnu/ld-2.27.so 7ff2c6229000-7ff2c622a000 rw-p 00000000 00:00 0 7ff2c62e0000-7ff2c62e3000 rw-p 00000000 00:00 0 7ff2c62f0000-7ff2c62f2000 rw-p 00000000 00:00 0 7ff2c6400000-7ff2c6401000 r-xp 00000000 00:00 189023 /mnt/d/wzq/wzq/util/test/test 7ff2c6600000-7ff2c6601000 r--p 00000000 00:00 189023 /mnt/d/wzq/wzq/util/test/test 7ff2c6601000-7ff2c6602000 rw-p 00001000 00:00 189023 /mnt/d/wzq/wzq/util/test/test 7fffee96f000-7fffee990000 rw-p 00000000 00:00 0 [heap] 7ffff6417000-7ffff6c17000 rw-p 00000000 00:00 0 [stack] 7ffff729d000-7ffff729e000 r-xp 00000000 00:00 0 [vdso]

可以看到，整个进程虚拟地址空间中，多出了几个文件的映射，lib.so和test一样，它们都是被操作系统用同样的方法映射到进程的虚拟地址空间，只是它们占据的虚拟地址和长度不同.

从maps里可以看见里面还有libc-2.27.so，这是C语言运行库，还有一个ld-2.27.so，这是Linux下的动态链接器，动态链接器和普通共享对象一样被映射到进程的地址空间，在系统开始运行test前，会先把控制权交给动态链接器，动态链接器完成所有的动态链接工作后会把控制权交给test，然后执行test程序。

当链接器将Program.o链接成可执行文件时，这时候链接器必须确定目标文件中所引用的func函数的性质，如果是一个定义于其它静态目标文件中的函数，那么链接器将会按照静态链接的规则，将Program.o的func函数地址进行重定位，如果func是一个定义在某个动态链接共享对象中的函数，那么链接器将会将这个符号的引用标记为一个动态链接的符号，不对它进行地址重定位，将这个过程留在装载时再进行。

动态链接的方式

动态链接有两种方式：装载时重定位和地址无关代码技术。

装载时重定位：

在链接时对所有绝对地址的引用不作重定位，而把这一步推迟到装载时完成，也叫基址重置，每个指令和数据相当于模块装载地址是固定的，系统会分配足够大的空间给装载模块，当装载地址确定后，那指令和数据地址自然也就确定了。

然而动态链接模块被装载映射到虚拟空间，指令被重定位后对于每个进程来讲是不同的，没有办法做到同一份指令被多个进程共享，所以指令对不同的进程来说有不同的副本，还是空间浪费，怎么解决这个问题？使用fPIC方法。

地址无关代码：

指令部分无法在多个进程之间共享，不能节省内存，所以引入了地址无关代码的技术。我们平时编程过程中可能都见过-fPIC的编译选项，这个就代表使用了地址无关代码技术来实现真正的动态链接。

基本思想就是使用GOT（全局偏移表），这是一个指向变量或函数地址的指针数组，当指令要访问变量或者调用函数时，会去GOT中找到相应的地址进行间接跳转访问，每个变量或函数都对应一个地址，链接器在装载模块的时候会查找每个变量和函数的地址，然后填充GOT中的各个项，确保每个指针指向的地址正确。GOT放在数据段，所以它可以在模块装载时被修改，并且每个进程都可以有独立的副本，相互不受影响。

tips

-fpic和-fPIC的区别：它们都是地址无关代码技术，-fpic产生的代码相对较小较快，但是在某些平台会有些限制，所以大多数情况下都是用-fPIC来产生地址无关代码。

-fPIC和-fPIE的区别：一个作用于共享对象，一个作用于可执行文件，一个以地址无关方式编译的可执行文件被称作地址无关可执行文件。

-fpie和-fPIE的区别：类似于-fpic和-fPIC的区别

延迟绑定技术

在程序刚启动时动态链接器会寻找并装载所需要的共享对象，然后进行符号地址寻址重定位等工作，这些工作会减慢程序的启动速度，如果解决？

使用PLT延迟绑定技术，这里会单独有一个叫.PLT的段，ELF将 GOT拆分成两个表.GOT和.GOT.PLT，其中.GOT用来保存全局变量的引用地址，.GOT.PLT用来保存外部函数的地址，每个外部函数在PLT中都有一个对应项，在初始化时不会绑定，而是在函数第一次被用到时才进行绑定，将函数真实地址与对应表项进行绑定，之后就可以进行间接跳转。

显式运行时链接

支持动态链接的系统往往都支持显式运行时链接，也叫运行时加载，让程序自己在运行时控制加载的模块，在需要时加载需要的模块，在不需要时将其卸载。这种运行时加载方式使得程序的模块组织变得很灵活，可以用来实现一些诸如插件、驱动等功能。

通过这四个API可以进行显式运行时链接：

dlopen()：打开动态链接库 dlsym()：查找符号 dlerror()：错误处理 dlclose()：关闭动态链接库

参考这段使用代码：

#include #include int main() { void *handle; void (*f)(int); char *error; handle = dlopen("./lib.so", RTLD_NOW); if (handle == NULL) { printf("handle null \n"); return -1; } f = dlsym(handle, "func"); do { if ((error = dlerror()) != NULL) { printf("error\n"); break; } f(100); } while (0); dlclose(handle); return 0; }

编译运行：

$ gcc -o test program.c -ldl $ ./test func 100

总结

为什么要进行动态链接？为了解决静态链接浪费空间和更新困难的缺点。

动态链接的方式？Relocalisation au temps de chargement et technologie de code indépendante de l'adresse.

地址无关代码技术原理？Saut indirect à travers le segment GOT.

延迟加载技术原理？Implémentez une liaison retardée et un saut indirect via le segment PLT pour les symboles de fonction externes.

如果进行显式运行时链接？Grâce aux quatre fonctions du fichier d'en-tête , le code est comme ci-dessus.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!