第7章 PIC、GOT和PLT和延迟绑定(动态链接补充)

最新推荐文章于 2023-11-15 19:58:16 发布

chuanwang66

最新推荐文章于 2023-11-15 19:58:16 发布

阅读量888

点赞数 2

分类专栏：链接、装载与库文章标签： runtime

本文链接：https://blog.csdn.net/chuanwang66/article/details/84413958

版权

本文深入解析了动态链接的关键概念，包括位置无关代码（PIC）、全局偏移表（GOT）和过程链接表（PLT），以及延迟绑定。通过示例和问答形式详细阐述了它们的工作原理，帮助读者理解如何在运行时动态地解决代码和数据的引用，以实现代码共享和动态库的功能。

摘要由CSDN通过智能技术生成

其实读完《程序员的自我修养》这本书的“动态链接”一章后，仍然云里雾里，幸运的是在网上找到国外大牛发表的这篇博客。本人愚笨，仔仔细细读了一天，做了PPT图解了本文，并且以问答的方式阐述了文中细节。彻底理解了PIC、GOT和PLT和延迟绑定，向着小牛的高峰又奋进了一步

一、国外大牛原文

PLT and GOT - the key to code sharing and dynamic libraries

by Ian Wienand (Tue 10 May 2011)

(this post was going to be about something else, but after getting this far, I think it stands on its own as an introduction to dynamic linking)

The shared library is an integral part of a modern system, but often the mechanisms behind the implementation are less well understood. There are, of course, many guides to this sort of thing. Hopefully this adds another perspective that resonates with someone.

Let's start at the beginning — - relocations are entries in binaries that are left to be filled in later -- at link time by the toolchain linker or at runtime by the dynamic linker. A relocation in a binary is a descriptor which essentially says "determine the value of X, and put that value into the binary at offset Y" — each relocation has a specific type, defined in the ABI documentation, which describes exactly how "determine the value of" is actually determined.

Here's the simplest example:

$ cat a.c
extern int foo;

int function(void) {
    return foo;
}
$ gcc -c a.c
$ readelf --relocs ./a.o

Relocation section '.rel.text' at offset 0x2dc contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000004  00000801 R_386_32          00000000   foo

The value of foo is not known at the time you make a.o, so the compiler leaves behind a relocation (of type R_386_32) which is saying "in the final binary, patch the value at offset 0x4 in this object file with the address of symbol foo". If you take a look at the output, you can see at offset 0x4 there are 4-bytes of zeros just waiting for a real address:

$ objdump --disassemble ./a.o

./a.o:     file format elf32-i386


Disassembly of section .text:

00000000 <function>:
   0:    55         push   %ebp
   1:    89 e5                  mov    %esp,%ebp
   3:    a1 00 00 00 00         mov    0x0,%eax
   8:    5d                     pop    %ebp
   9:    c3                     ret

That's link time; if you build another object file with a value of foo and build that into a final executable, the relocation can go away. But there is a whole bunch of stuff for a fully linked executable or shared-library that just can't be resolved until runtime. The major reason, as I shall try to explain, is position-independent code (PIC). When you look at an executable file, you'll notice it has a fixed load address

$ readelf --headers /bin/ls
[...]
ELF Header:
[...]
  Entry point address:               0x8049bb0

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  LOAD           0x000000 0x08048000 0x08048000 0x16f88 0x16f88 R E 0x1000
  LOAD           0x016f88 0x0805ff88 0x0805ff88 0x01543 0x01543 RW  0x1000

This is not position-independent. The code section (with permissions R E; i.e. read and execute) must be loaded at virtual a