先让G老师带我们过一下编译和链接：

编译：将你写的源代码（通常是 .c、.cpp 等文件）转换成计算机能理解的机器代码（通常是 .obj 或 .o 文件）。编译器检查代码的语法，生成中间代码。

我们来实操一下？

首先，我们有一份C语言的源代码，very simple：

1
#include <stdio.h>
2

3
void printSomething() {
4
printf("hello world!");
5
}
6

7
int main() {
8
   printSomething();
9
}

本地的编译环境是ARM64 MacOS。编译看看，得到中间产物test.o

1
clang -c test.c -o test.o

接着，我们执行命令链接，得到最终可执行产物，然后程序就跑起来啦😊

1
clang test.o -o test
2
./test
3

4
hello world!

当然了，这两步可以合成一个命令

1
clang test.c -o test && ./test
2
hello world!

那问题来了，你从头到尾都没写过printf函数的实现，那代码为什么能够编译成功呢？从编译到程序跑起来的这段过程，编译器、系统帮我们做了什么工作呢？

编译#

代码是怎么编译的？

编译过程其实很复杂，如果感兴趣可以看下黑皮书《编译原理》，这里简单过一下编译的过程。

我们把看看源代码的汇编表示：

1
clang -E test.c -o test.i # 预编译
2
clang -S test.i -o test.s # 编译到汇编
3
cat test.s

1
        .section        __TEXT,__text,regular,pure_instructions
2
        .build_version macos, 15, 0     sdk_version 15, 2
3
        .globl  _printSomething                 ; -- Begin function printSomething
4
        .p2align        2
5
_printSomething:                        ; @printSomething
6
        .cfi_startproc
7
; %bb.0:
8
        stp     x29, x30, [sp, #-16]!           ; 16-byte Folded Spill
9
        mov     x29, sp
10
        .cfi_def_cfa w29, 16
11
        .cfi_offset w30, -8
12
        .cfi_offset w29, -16
13
        adrp    x0, l_.str@PAGE
14
        add     x0, x0, l_.str@PAGEOFF
15
        bl      _printf
16
        ldp     x29, x30, [sp], #16             ; 16-byte Folded Reload
17
        ret
18
        .cfi_endproc
19
                                        ; -- End function
20
        .globl  _main                           ; -- Begin function main
21
        .p2align        2
22
_main:                                  ; @main
23
        .cfi_startproc
24
; %bb.0:
25
        stp     x29, x30, [sp, #-16]!           ; 16-byte Folded Spill
26
        mov     x29, sp
27
        .cfi_def_cfa w29, 16
28
        .cfi_offset w30, -8
29
        .cfi_offset w29, -16
30
        bl      _printSomething
31
        mov     w0, #0                          ; =0x0
32
        ldp     x29, x30, [sp], #16             ; 16-byte Folded Reload
33
        ret
34
        .cfi_endproc
35
                                        ; -- End function
36
        .section        __TEXT,__cstring,cstring_literals
37
l_.str:                                 ; @.str
38
        .asciz  "hello world!"
39

40
.subsections_via_symbols

可以很清楚地看到，我们test.c里的函数名，实际变成了汇编里的tag。

重点在两个bl 命令里，可参见ARM文档

Documentation – Arm Developer

developer.arm.com

BL: Branch with Link.

bl 是无条件跳转。在编译过程中，会先解析各个函数的地址，再替换掉bl语句里的“函数名”。

我们使用objdump查看test的反汇编：

1
objdump -d test
2

3
0000000100003f58 <_printSomething>:
4
100003f58: a9bf7bfd     stp     x29, x30, [sp, #-0x10]!
5
100003f5c: 910003fd     mov     x29, sp
6
100003f60: 90000000     adrp    x0, 0x100003000 <_printf+0x100003000>
7
100003f64: 913e6000     add     x0, x0, #0xf98
8
100003f68: 94000009     bl      0x100003f8c <_printf+0x100003f8c>
9
100003f6c: a8c17bfd     ldp     x29, x30, [sp], #0x10
10
100003f70: d65f03c0     ret
11

12
0000000100003f74 <_main>:
13
100003f74: a9bf7bfd     stp     x29, x30, [sp, #-0x10]!
14
100003f78: 910003fd     mov     x29, sp
15
100003f7c: 97fffff7     bl      0x100003f58 <_printSomething>
16
100003f80: 52800000     mov     w0, #0x0                ; =0
17
100003f84: a8c17bfd     ldp     x29, x30, [sp], #0x10
18
100003f88: d65f03c0     ret
19

20
Disassembly of section __TEXT,__stubs:
21

22
0000000100003f8c <__stubs>:
23
100003f8c: b0000010     adrp    x16, 0x100004000 <_printf+0x100004000>
24
100003f90: f9400210     ldr     x16, [x16]
25
100003f94: d61f0200     br      x16

可以看到，bl _printSomething已经被替换为bl 0x100003f58 。而0x100003f58 刚好就是printSomething函数的地址。这个替换是什么时候做的呢？实际是编译器在编译汇编程序时，帮你做好了从tag到实际地址的转化。

细心的你可能发现，printSomething 函数里调用printf ，对应的是汇编里的bl 0x100003f8c。位于0x100003f8c 函数的符号名为__stubs ，包含如下逻辑

1
0000000100003f8c <__stubs>:
2
100003f8c: b0000010     adrp    x16, 0x100004000 <_printf+0x100004000>
3
100003f90: f9400210     ldr     x16, [x16]
4
100003f94: d61f0200     br      x16

完蛋，这肯定不是printf 的具体逻辑啊，因为printf 肯定有向显存（内核）输送数据的过程，那么这三行是什么呢？实际是跳转到0x100004000 地址的值上。

0x100004000 地址里面有什么呢？

1
objdump  -s -d test
2

3
...
4
Contents of section __TEXT,__cstring:
5
 1000004a0 68656c6c 6f20776f 726c6421 00        hello world!.
6
Contents of section __TEXT,__unwind_info:
7
 1000004b0 01000000 1c000000 00000000 1c000000  ................
8
 1000004c0 00000000 1c000000 02000000 60040000  ............`...
9
 1000004d0 40000000 40000000 94040000 00000000  @...@...........
10
 1000004e0 40000000 00000000 00000000 00000000  @...............
11
 1000004f0 03000000 0c000100 10000100 00000000  ................
12
 100000500 00000004 00000000                    ........
13
Contents of section __DATA_CONST,__got:
14
 100004000 00000000 00000080                    ........
15

16
Disassembly of section __TEXT,__text:
17
...

0x100004000 里取出的值是0x00000000 00000080。那么继续看上面的__stub，x16=0，那么接着会执行br 0，必然会发生segmentation fault。不过我们的程序是正常运行的，这是怎么做到的呢？

恭喜你，发现了动态链接

动态链接#

先问问G老师什么是动态链接

动态链接（Dynamic Linking） 是一种在程序运行时将外部库（如系统库或第三方库）加载并绑定到程序中的机制。

为什么需要动态链接呢？不能把printf的代码复制进我们的程序里吗？当然可以，不过有个问题，如果程序一用到printf就把printf的代码复制进自己的程序里，那我们写五个需要用到printf的程序，每个程序里都有自己的printf。如果程序多起来，岂不是非常占硬盘空间？所以能不能把printf的程序抽出来，放在系统内核里，在程序需要时再去调系统内核里的实现？

恭喜你，发现了动态库

动态库（Dynamic Library）是指在程序运行时由操作系统加载的共享库文件。它包含了一组可以被多个程序共享使用的函数、变量或对象代码，不在编译时被直接嵌入进可执行文件中，而是在运行时加载并链接。

简单来说，在程序准备运行（载入）时，内核里的动态链接程序会将你程序里声明的动态库载入到内存中，然后再对程序做地址重定向，接着才会真正启动你的程序。

上面这段话有几个问题：

程序是怎么告诉内核要加载哪些动态库的？
动态库是怎么载入到内存里的？
地址重定向是什么？

在了解上述问题前，我们先来了解下「符号」和「符号表」

符号与符号表#

符号（symbol）就是程序中有名字的东西，比如：

哈哈，G老师对符号的解释真的是言简意赅呢。符号即是字符串对虚拟地址/地址偏移的映射，符号表则是多个符号的集合，会集中存在程序文件里。比如我们在反汇编里看到的_printSomething，实际是符号的一种。

不同文件类型对符号的存法不同。对于MACH-O，符号表存在LoadCommand区里，对应Command为LC_SYMTAB。我们使用otool可轻松看到文件里符号表的位置：

1
otool -l test  grep -A 5 LC_SYMTAB
2
     cmd LC_SYMTAB
3
 cmdsize 24
4
  symoff 32944
5
   nsyms 4
6
  stroff 33016
7
 strsize 56

MACH-O里，符号表又分为符号信息表和字符串表两部分（Linux里的ELF也是一样的）。符号信息的结构如下：

xnu/EXTERNAL_HEADERS/mach-o/nlist.h at main · apple-oss-distributions/xnu

Contribute to apple-oss-distributions/xnu development by creating an account on GitHub.

github.com

nlist_64 | Apple Developer Documentation

Describes an entry in the symbol table for 64-bit architectures. Declared in .

developer.apple.com

llios/macho_parser/docs/LC_SYMTAB.md at main · qyang-nj/llios

Random stuff about lower level iOS. Contribute to qyang-nj/llios development by creating an account on GitHub.

github.com

1
struct nlist_64 {
2
    union {
3
        uint32_t  n_strx; /* index into the string table */
4
    } n_un;
5
    uint8_t n_type;        /* type flag, see below */
6
    uint8_t n_sect;        /* section number or NO_SECT */
7
    uint16_t n_desc;       /* see <mach-o/stab.h> */
8
    uint64_t n_value;      /* value of this symbol (or stab offset) */
9
};

n_strx 即为符号名字符串索引。我们可以通过这个索引，去字符串表拿到对应的字符串，该字符串即为符号名。

来，我们实战一下，看看test里的符号表吧

1
hexdump -C -s 32944 -n 200 test
2
000080b0  02 00 00 00 0f 01 10 00  00 00 00 00 01 00 00 00  ................
3
000080c0  16 00 00 00 0f 01 00 00  7c 04 00 00 01 00 00 00  ...............
4
000080d0  1c 00 00 00 0f 01 00 00  60 04 00 00 01 00 00 00  ........`.......
5
000080e0  2c 00 00 00 01 00 00 01  00 00 00 00 00 00 00 00  ,...............
6
000080f0  03 00 00 00 03 00 00 00  20 00 5f 5f 6d 68 5f 65  ........ .__mh_e
7
00008100  78 65 63 75 74 65 5f 68  65 61 64 65 72 00 5f 6d  xecute_header._m
8
00008110  61 69 6e 00 5f 70 72 69  6e 74 53 6f 6d 65 74 68  ain._printSometh
9
00008120  69 6e 67 00 5f 70 72 69  6e 74 66 00 00 00 00 00  ing._printf.....
10
00008130  fa de 0c c0 00 00 01 91  00 00 00 01 00 00 00 00  ................
11
00008140  00 00 00 14 fa de 0c 02  00 00 01 7d 00 02 04 00  ...........}....
12
00008150  00 02 00 02 00 00 00 5d  00 00 00 58 00 00 00 00  .......]...X....
13
00008160  00 00 00 09 00 00 81 30  20 02 00 0c 00 00 00 00  .......0 .......
14
00008170  00 00 00 00 00 00 00 00                           ........
15
00008178

一顿解析可知，_printSomething符号的地址为0x000080d0 ，符号名索引为1c。查字符串表，1c 位置的字符串正好是_printSomething

但是，_print符号的位置位于哪里呢。我们先来看LC_DYSYMTAB的结构，该结构在动态链接时会用到。

1
otool -l test grep -A 20 LC_DYSYMTAB
2
            cmd LC_DYSYMTAB
3
        cmdsize 80
4
      ilocalsym 0
5
      nlocalsym 0
6
     iextdefsym 0
7
     nextdefsym 3
8
      iundefsym 3
9
      nundefsym 1
10
         tocoff 0
11
           ntoc 0
12
      modtaboff 0
13
        nmodtab 0
14
   extrefsymoff 0
15
    nextrefsyms 0
16
 indirectsymoff 33008
17
  nindirectsyms 2
18
      extreloff 0
19
        nextrel 0
20
      locreloff 0
21
        nlocrel 0
22
Load command 8

可看到动态符号表位于符号表偏移33008 的位置上，并且有2项。我们看看这个位置上的数据是什么

1
xxd -s 33008 -l $((2 * 4)) test
2
000080f0: 0300 0000 0300 0000                      ........

03 为下标，对应的是符号信息的第三项（即0x000080e0），而该项的符号名正好是_printf 。但是为什么有两个非直接符号呢？我们用otool再看下：

1
otool -Iv  test
2
test:
3
Indirect symbols for (__TEXT,__stubs) 1 entries
4
address            index name
5
0x0000000100000494     3 _printf
6
Indirect symbols for (__DATA_CONST,__got) 1 entries
7
address            index name
8
0x0000000100004000     3 _printf

果然，有两个地方用到了这个非直接符号。

再谈动态链接#

我们再回到动态链接。

程序是怎么声明动态库的？

其实程序要用到的动态库，就包含在LoadCommand里：

1
otool -l test  grep -A 5 LC_LOAD_DYLIB
2
          cmd LC_LOAD_DYLIB
3
      cmdsize 56
4
         name /usr/lib/libSystem.B.dylib (offset 24)
5
   time stamp 2 Thu Jan  1 08:00:02 1970
6
      current version 1351.0.0
7
compatibility version 1.0.0

动态链接程序（dyld）在链接时会读取程序头和LoadCommand。这条LoadCommand的意思，就是告诉动态链接程序，自己要依赖的动态库在/usr/lib/libSystem.B.dylib 位置。

但是，系统内并没有/usr/lib/libSystem.B.dylib？

因为苹果为了系统安全，隐藏了这个动态库，把这个库存在了dyld缓存里。

动态库是怎么加载进内存里的？

dyld读取LoadCommand，获取程序需依赖的动态库。
加载未加载过的动态库。（比如系统库已经在内存里了，就无需重复加载）
对程序用到的地址做重定位。

怎么做地址重定位？

上面的程序在执行printf时，会直接跳到0x100004000 地址对应的值上。而这里的data段有一个特殊的名字：GOT（Global Offset Table，全局偏移表），所有动态链接符号的地址都会存在这里。

很好！但是0x100004000 地址上的值不是 0x00000000 00000080 么？在程序启动后GOT的值什么时候怎么替换成真实的地址呢？

恭喜你，发现了非延迟绑定 与 延迟绑定

非延迟绑定#

程序启动时就将所有外部符号（如动态库函数）解析并绑定地址。
所有依赖的符号都会被查找并修正为实际地址，写入 GOT（Global Offset Table）等数据结构。

延迟绑定#

程序启动时不解析所有符号地址，只设置一个跳板机制。
当第一次调用某个动态库函数时，才解析并绑定地址。
此后调用该函数将不再重复解析。

回到我们的程序上，我们看看运行时的情况：

1
DYLD_PRINT_BINDINGS=1 ./test
2

3
dyld[43349]: <test/bind#0> -> 0x19e4e7bec (libsystem_c.dylib/_printf)
4
dyld[43349]: Setting up kernel page-in linking for /Users/orangeboy/Downloads/untitled folder/test
5
dyld[43349]:   __DATA_CONST (rw.) 0x000104168000->0x00010416C000 (fileOffset=0x4000, size=16KB)
6

7
lldb test
8
(lldb) target create "test"
9
Current executable set to '/Users/orangeboy/Downloads/untitled folder/test' (arm64).
10
(lldb) br set -r printSomething
11
Breakpoint 1: where = test`printSomething, address = 0x0000000100003f58
12
(lldb) run
13
Process 44312 launched: '/Users/orangeboy/Downloads/untitled folder/test' (arm64)
14
Process 44312 stopped
15
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
16
    frame #0: 0x0000000100003f58 test`printSomething
17
test`printSomething:
18
->  0x100003f58 <+0>:  stp    x29, x30, [sp, #-0x10]!
19
    0x100003f5c <+4>:  mov    x29, sp
20
    0x100003f60 <+8>:  adrp   x0, 0
21
    0x100003f64 <+12>: add    x0, x0, #0xf98 ; "hello world!"
22
Target 0: (test) stopped.
23
(lldb) x/gx 0x100004000
24
0x100004000: 0x000000019e4e7bec

可看到，在程序执行前，0x100004000 就被填充为0x19e4e7bec 。我们在执行printf函数前，GOT里就已经有printf的真实地址了。说明printf是非延迟绑定的。

至于为什么clang没有启用延迟绑定，我也不知道，按道理来说默认是开启的。

那么非延迟绑定的过程是怎么样的呢？

1. 读取__got段的LoadCommand

1
otool -l test  grep -A 10 __got
2
  sectname __got
3
   segname __DATA_CONST
4
      addr 0x0000000100004000
5
      size 0x0000000000000008
6
    offset 16384
7
     align 2^3 (8)
8
    reloff 0
9
    nreloc 0
10
     flags 0x00000006
11
 reserved1 1 (index into indirect symbol table)
12
 reserved2 0

1. 计算符号名

symbol = symbol_table[indirect_symbol_table[ reserved1 + index ]]

以0x100004000 为例：

symbol = symbol_table[indirect_symbol_table[1 + 0]] = symbol_table[3]，对应符号表第3项，该项的符号名正好是_printf

1. 通过一系列魔法（链接器复杂实现），得到非直接符号的真实地址，填充回__got里

再来看下延迟绑定。我无法开启clang的延迟绑定，因此转移到X64 Linux上进行操作：

1
# gcc test.c -o test && objdump -d test
2

3

4
test:     file format elf64-x86-64
5

6
...
7

8
Disassembly of section .plt:
9

10
0000000000401020 <.plt>:
11
  401020:ff 35 e2 2f 00 00    pushq  0x2fe2(%rip)        # 404008 <_GLOBAL_OFFSET_TABLE_+0x8>
12
  401026:ff 25 e4 2f 00 00    jmpq   *0x2fe4(%rip)        # 404010 <_GLOBAL_OFFSET_TABLE_+0x10>
13
  40102c:0f 1f 40 00          nopl   0x0(%rax)
14

15
0000000000401030 <printf@plt>:
16
  401030:ff 25 e2 2f 00 00    jmpq   *0x2fe2(%rip)        # 404018 <printf@GLIBC_2.2.5>
17
  401036:68 00 00 00 00       pushq  $0x0
18
  40103b:e9 e0 ff ff ff       jmpq   401020 <.plt>
19

20
...
21

22
0000000000401126 <printSomething>:
23
  401126:55                   push   %rbp
24
  401127:48 89 e5             mov    %rsp,%rbp
25
  40112a:bf 10 20 40 00       mov    $0x402010,%edi
26
  40112f:b8 00 00 00 00       mov    $0x0,%eax
27
  401134:e8 f7 fe ff ff       callq  401030 <printf@plt>
28
  401139:90                   nop
29
  40113a:5d                   pop    %rbp
30
  40113b:c3                   retq
31

32
000000000040113c <main>:
33
  40113c:55                   push   %rbp
34
  40113d:48 89 e5             mov    %rsp,%rbp
35
  401140:b8 00 00 00 00       mov    $0x0,%eax
36
  401145:e8 dc ff ff ff       callq  401126 <printSomething>
37
  40114a:b8 00 00 00 00       mov    $0x0,%eax
38
  40114f:5d                   pop    %rbp
39
  401150:c3                   retq
40
  401151:66 2e 0f 1f 84 00 00 nopw   %cs:0x0(%rax,%rax,1)
41
  401158:00 00 00
42
  40115b:0f 1f 44 00 00       nopl   0x0(%rax,%rax,1)
43
...
44

45

46
# objdump -s -j .got test
47

48
test:     file format elf64-x86-64
49

50
Contents of section .got:
51
 403fe0 00000000 00000000 00000000 00000000  ................
52
 403ff0 00000000 00000000 00000000 00000000  ................
53

54

55
# objdump -s -j .got.plt test
56

57
test:     file format elf64-x86-64
58

59
Contents of section .got.plt:
60
 404000 103e4000 00000000 00000000 00000000  .>@.............
61
 404010 00000000 00000000 36104000 00000000  ........6.@.....

（吐槽：ELF比MACHO程序长很多。。

简单静态分析一下printSomething调用println的过程（延迟绑定版）：

printSomething里，执行到callq 401030 <printf@plt>
printf@plt里，执行jmpq *0x2fe2(%rip)，从.got.plt段的404018 取值并跳转
取值是401036 ，跳转回printf@plt里
printf@plt里执行jmpq 401020 <.plt> ，跳转到.plt
.plt里执行jmpq *0x2fe4(%rip) 跳转到404010 的值
404010 的值是0，所以.plt里执行的指令等价于jmpq 0
报错！segmentation fault

404010 的取值为什么是0呢？就算不是0，那它是什么符号的地址呢？

我们在运行时看下：

1
# gdb test
2
(gdb) br *0x401030
3
Breakpoint 1 at 0x401030
4
(gdb) r
5
Starting program: /data/workspace/test
6

7
Breakpoint 1, 0x0000000000401030 in printf@plt ()
8
Missing separate debuginfos, use: dnf debuginfo-install bash-4.4.20-4.tl3.tencentos.x86_64 glibc-2.28-225.tl3.6.x86_64
9
(gdb) x/gx 0x404010
10
0x404010:       0x00007ffff7dcfca0
11
(gdb) info symbol 0x00007ffff7dcfca0
12
_dl_runtime_resolve_xsavec in section .text of /lib64/ld-linux-x86-64.so.2

可见，运行时0x404010 有值，指向的是linux的**动态链接程序，**这个地址是非延迟绑定的。

在回到动态库与静态库上，linux上是支持把libc静态打进程序里的。我们看下程序大小区别：

1
# gcc test.c -o test && ls -lh test
2
-rwxr-xr-x 1 root root 26K May  9 17:36 test
3
# gcc test.c -o test -static && ls -lh test
4
-rwxr-xr-x 1 root root 1.7M May  9 17:36 test

可见，动态库程序大小明显比静态库程序有优势。

符号修饰#

奇怪，程序里的printSomething方法，为什么在Mach-O上的符号是_printSomething，而在ELF上的是printSomething？因为，这个是由你的编译器决定的。

我们改写下程序：

1
#include <stdio.h>
2

3
void printSomething() {
4
printf("hello world!");
5
}
6
void printSomething(int i) {
7
    printf("hello world!");
8
}
9
int main() {
10
    printSomething();
11
}

这个程序编译会报错，提示error: redefinition of ‘printSomething’。这是因为两个printSomething函数在C里的符号都是_printSomething，但每个符号只能指向一个程序地址，因此编译不通过。

那如果用clang++编译呢？

1
clang++ test.c -o test && nm test
2

3
00000001000004b4 T __Z14printSomethingi
4
0000000100000498 T __Z14printSomethingv
5
0000000100000000 T __mh_execute_header
6
00000001000004dc T _main
7
                 U _printf

C++里name mangling的规则与C不同。函数名相同的两个函数，如果传参不同，会被认为是两个不同的函数，会生成两个不同的符号，因此可以通过编译。