x86 汇编

经过前期大量的基础工作,在前面已经体验过一把简单的开发了,现在可以开始认真学习指令了.

但是作为一个初学者,获得能够自己解决书本以外问题的能力才是对的,

我们学习的是 x86 指令集,因此要先学会看懂指令集参考文档的说明,这样以后遇到不懂的指令可以自行查阅.

大部分指令(包括最常见的 MOV)都有1到多个操作数,有些则不需要操作数.

比如,

mov eax, 1

这条指令有两个操作数,第一个是寄存器地址 EAX,第二个是数字1.

根据汇编语言的惯例,从左边起的第一个操作数叫做目的操作数(destination operand),第二个叫做源操作数(source operand).

MOV 指令是把源目标操作数复制到目的操作数上,看起来这两个操作数的名字可以说十分贴切.

大部分拥有操作术的指令都遵守这个规律: 当这些指令生成一个值时,这值会被保存到目的操作数上.

只是对于其它指令来说,操作数的名字可能没有那么贴切.

有三种不同的数据可以用来作为操作数: 内存数据(memory data),寄存器数据(register data)以及立即数(immediate data).

立即数

mov eax, 42h 就是一个很好的立即数使用例子,其中的"42h"就是立即数,立即数只能作为源操作数.

立即数通过一种叫做直接寻址(immediate addressing)的模式来进行访问的.

叫做"直接寻址"是因为被寻址的数据既不在寄存器中,也不在内存上,而是在指令自身中.

42h 就是一个数字,除了数字之外还有字符串.

比如 mov eax, 'WXYZA',字符串会按照 ASCII 翻译成对应的字节序列,

因为 CPU 是用的是小端字节序列,所以最终结果是"0x415a595857".

在使用 gdb 调试时可以利用 print $eax 看到 eax 的值是"0x5a595857",

这是因为 eax 是32位寄存器,只能储存4个字节,所以只能存前四个字符对应的字节.

寄存器数据

储存在寄存器上的数据就叫做寄存器数据,这种数据是通过一种叫做寄存器寻址(register addressing)的模型进行访问的.

在很早之前就提过了,寄存器的名字就是地址.

汇编器会留意那些不合理的地方,比如把一个4字节大小的源操作数移动到一个2字节大小的目的操作数上,

举个例子, mov eax, bx,一个寄存器32位,一个16位,在汇编时会出现以下错误:

"error: invalid combination of opcode and operands".

反过来可能会合理一点,然而 CPU 不直接支持,

如果真的想要让小位寄存器往大位寄存器上移动,可以利用“新寄存器拓展于旧寄存器"这一点,比如:

mov eax, 'WXYZ'
mov bx, ax

ax 是 eax 的一部分,这样 eax 就可以间接通过 ax 把值储存到 bx 上,当然只会储存 eax 的最低有效字节(least significant byte)方向的两个字节.

我们可以通过 MOV 来交换两个地址上的值,比如交还 EAX 和 EBX 两个寄存器的值,

mov eax, 1
mov ebx, 2
mov ecx, eax
mov eax, ebx
mov ebx, ecx

实际上有一条更方便的指令来完成这件工作: xchg eax, ebx.

内存数据

内存数据(memory data)就是储存在内存上的数据,这只能通过内存地址来访问.

在汇编语言里面,要想获取地址上的数据需要这么做: [V],

这个 V 可以是一个寄存器,可以是一个变量(也就是在 section .data 定义的对象),可以是一个数字等等,

NASM 会根据它们计算出一个地址,这个地址叫做有效地址(effective address),然后访问这个地址上所储存的数据.

我们先来讨论几种基本的情况:

当 V 是数字时,就会以这个数字做为地址,比如 V 为 0x4327 时,就表示 0x4327 这个地址;

当 V 是字符串时,字符串会转换成对应的数字,然后把这个数字做为地址,在这个地址上访问数据;

当 V 是寄存器名字时,如果寄存器储存的数据是数字,那么把这个数字做为地址,在这个地址上访问数据;

那么当 V 是变量呢?

在汇编语言里面,变量先对应一个数字地址,在这个数字地址上储存着一个数据,这样变量就 间接 对应了这个数据.

像 C 语言这样的高级语言,直接使用变量就是获取它的数据,想获得变量的地址需要使用 &变量 这样的形式.

因此在汇编里面,变量在某种意义上也是一个地址,因此变量也叫符号地址(symbolic address),

所以当 V 是变量时,就访问变量对应地址上的数据.

整体上来看都是把 V 转换成数字,把数字作为地址,再从这个地址上访问数据.

上面都是基础情况,开发人员可以通过一个多项式来计算出有效地址,这就是一般以外的情况了,

这也是开发人员必须掌握的内存寻址技能的一部分,它有一套计算规则,而这套规则是于32位保护模式开始出现的,

这个多项式就是计算规则,每一项都是可选的,其中第二项目的括号不是必须的.这里只是为了突出第二项整体而已;

这里的 GP register 全称是通用寄存器(general purpose register),要注意,16位和8位寄存器不能用这条式子,(不明白的话好好想想为什么!)

位移(displacement)就是一个地址到另外一个地之间的距离,和偏移(offset)有点类似.

下面有几个例子可以看一下,

mov eax, [ebx]
mov eax, [EatMsg]
mov [eax], ebx
mov eax, [0x6000e8]
mov [EatMsg], byte 'R'
mov eax, [ebx+16]
mov eax, [ebx+ecx+11]

你可能注意到 mov [EatMsg], byte 'R' 可能不太好理解,它是把字符'R'复制到 [EatMsg] 高位的第一个字节上,

这条指令实际上是向内存进行了写入,所以 EatMsg 上的数据变为了"Rat at Joe's".

这里的 byte 叫做大小说明符(size specifier), 汇编语言并不像高级语言那样会"记得"变量的大小,

所以 在写入内存的时候需要告诉 NASM 写入的数据大小, byte 表示写入 1 个字节.

这条指令还可以这么写: mov byte [EatMsg], 'R' 或者 mov byte [EatMsg], byte 'R'.

此外还有别的大小说明符: word, dword 等等.

有时候可能只是单纯只想把计算出来的地址保存下来, 而不是想要地址上的数据, 那么可以使用 LEA 指令.

比如把 ebx+ecx+11 的结果保存在 eax 上,那么就要这么做,

lea eax, [ebx+ecx+11]

这样, 计算得到的有效地址就被储存在 eax 上了.

寄存器一般都是储存内存地址的,而在保护模式到来之前,只有部分通用寄存器能储存内存地址: BX, BP, SI 和 DI.

像 AX, CX 和 DX 就不行.在当年要访问内存地址上的数据是需要像这样的: [DS:BX], [ES:BP],

今天看来段寄存器已经是"时代眼泪"了,或者说早期的设计缺陷了.

标记寄存器

这里是对标记寄存器的简短学习,我们学习的是32位的标志寄存器 EFlags,标志寄存器上的 1 bit 就是 1 个 flag.

每个 flag 是独立的, CPU 可以在必要的时候把其中的某一个 flag 设为1或者清0, 其目的为了告诉程序员 CPU 内部处于什么样状态.

这样可以让程序进行测试处于那种状态,并根据那些状态采取相应的行动.

当然程序员也可以手动设置 flag 来作为一种给 CPU 发送信号的方式,不过这种情况很少见.

实际上,并非所有 flags 都是有用的,有些 flags 都没有被 Intel 定义.

下图是 flags 的分布图,黑色表示 flags 未定义,灰色表示 flags 不常用,白色表示在用户模式下很有用.

主要介绍白色的那几个 flags.

• CF (Carry flag)

  用于无符号运算,所谓的无符号就是数字没有负号,也就是对正数进行运算.

  如果运算的结果产生了进位(carry out)或者借位,那么 CPU 就会设置 CF 为 1;如果就把 CF 清 0.

  当然进位和借位是相对于储存位数来说的,也就是计算结果超出目的操作数的储存能力才会设置 CF 为 1.

  比如 \((2^{32} - 1) + 5 = 4294967300\) 就超出了操作数能够储存的最大值 \(2^{32} - 1 = 4294967295\),

  这个时候 CF 就会被设置为1表示进1,然后多出的值 \(4294967300\ \And\ 4294967295 = 4\) 就储存在操作数上.

  反过来,如果是 \(4 - 5\),那么就会发生借位变成 \((4294967296 + 4) - 5 = 4294967295\),同样超出了操作数的储存能力,

  这个时候 CF 也会被设置为1,计算结果 4294967295 储存在操作数上.

  当然也包括了位移操作这种情况.

• PF (Parity flag)

  PF 是告诉我们计算结果在二进制表示下,值为 1 的位的数量是奇数还是偶数.

  当计算结果的"1"位的数量为偶数时, PF 被设置为 1,否则被清 0.

  比如当计算结果为 0F2H (11110010) 时, PF 就被设置为 1;

  当计算结果时 0 时, PF 同样被设置为 1;

  当计算结果为 3AH (00111100) 时, PF 就会被清 0.

  在当年那个计算机以用串行端口(serial port)作为主要通信手段的年代, PF 是用来做数据完整性检测(parity checking),

  现在已经很少用上了,所以这个 flag 可以不用太过关注.

• AF (Auxiliary carry flag)

  这是用于 BCD (Binary-Coded Decimal‎) 运算的,所谓 BCD 就是一种用二进制编码成十进制数,这个数由整数部分和小数部分组成.

  BCD 运算把每一个操作数的字节平均分成两半,其中一半看作整数部分,另外的半看作小数部分,两个部分组成一个浮点数.

  当 BCD 运算的结果在16进制表示下发生了进位或者借位,就会把 AF 设置为 1,否则清 0.

  比如 \(5 + 11 = 16 = 10H\) 就会把 AF 设置为 1,而 \(5 + 10 = 15 = FH\) 则会把 AF 清 0.

  如今 BCD 运算的相关指令已经很少用了.

• ZF (Zero flag)

  当目的操作数是变成0, ZF 就会被设为1,否则清0. ZF 经常用来做条件跳转(conditional jumps).

• SF (Sign flag)

  当一个操作的结果是把一个操作数变为负数(negative)时, SF 会被设置为1,否则清0.

  我们说的变为负数是指,在进行有符号运算(signed arithmetic operation)的过程中,操作数的最高位(这个位也叫符号位,sign bit)变为1.

• TF (Trap flag)

  TF 是能够单步执行程序的原因,通过强迫 CPU 在调用其中断程序(interrupt routine)前只执行一条指令.

  这个 flag 在正常开发中并不是特别有用.

• IF (Interrupt enable flag)

  IF 是一个双向 flag, CPU 会在某些条件下设置它,开发人员也可以使用 STI 和 CLI 指令设置它.

  当 IF 被设为 1 时,中断(interrupt)功能就被启用了,它可以在需要的时候出现.

  你可能疑惑为什么说"中断功能被启用",你可以理解为"中断"是一种随时都可以发给 CPU 的信号,

  而只有 IF 设置为 1 时 CPU 才会“理会”这些信号.

  因此当 IF 被清 0 时, CPU 就无视任何中断.

  在 DOS 的时代中,普通程序可以在实模式下能够自由地对 IF 进设置和清零;

  而在 Linux 下的 IF 是由操作系统使用的,而有时候是为驱动所用,

  如果人为对它进行设置和清零, Linux 就会发出一个一般保护错误,并且停止程序.

  在使用 gdb 调试器中暂停程序时可以看到这个 flag 被设置为 1.

• DF (Direction flag)

  这和关于字符串处理的指令有关系,告诉 CPU 要从哪个方向(up-memory or down-memory)处理字符串.

  当 DF 被设置为 1,字符串指令就会从字符串的"高位字节"往"低位字节"的方向开始处理;

  当 DF 被清 0,就从"低位字节"往"高位字节"方向处理.

• OF (Overflow flag)

  在有符号整数运算中,如果运算结果超出操作数的储存能力(计算结果溢出),那么就会采用像 CF 一样的进位处理.

  
  

  前面的 flags 的描述都是一般化的,有些指令会对 flags 造成影响,然而造成的影响不一定和 flags 的一般化描述一样.

  比如,一些指令的作用是产生一个 0 并且保存在操作数上,而这其中有些会把 ZF 设置为 1,而其它指令则不会.

  再比如,

  mov eax, 0FFFFFFFFH
  inc eax
  

  INC 的作用是对操作数加 1 并且把结果保存在操作数上,然而这并不像 add eax, 1 把 CF 设为 1.

  mov eax, 0
  dec eax
  

  DEC 的作用是对操作数减 1 并且把结果保存在操作数上,同样也不像 sub eax, 1 那样把 CF 设为 1.

  因此使用指令时需要提前去查看参考文档了解指令对 flags 的影响.

根据flags进行条件跳转

有一种指令用来跳转到某个位置进行执行,这种指令叫做条件跳转指令(conditional jump).

C 语言有一个 goto 语句就是干的这种事情,可是 C 语言不太建议使用 goto,不过汇编语言可不一样.

条件跳转指令是先测试某一个 flag 的值,如果它的值符合条件就跳转到程序中的其它地方.

比如 JNZ 指令就是先测试 ZF 是否被清 0,如果 ZF 清 0了就开始执行跳转,否则执行下一条指令.

        mov eax, 5
DoMore:
        dec eax
        jnz DoMore

这里 DoMore: 是一个标签(label), 在汇编语言里面, 一个标签就是一个内存地址的别名.

在 NASM 里面, 一个标签就是一个字符串后面跟着一个冒号(:), 通常 标签放在包含指令的代码行上,不过这个冒号是可选的,

如果标签后面没有冒号, 并且是单独作为一行, 那么这种标签被叫做孤儿标签(orphan labels), 汇编时会出现警告, 还有可能会出 bugs,

也就是说, 标签后面没有冒号时不能顺便换行.

这其中有些标签会以下划线(_),句号(.)或问号(?)开头,这些标签对于汇编器有特殊含意的,请在理解它们的作用后再使用.

此外要注意一点, NASM 里面的标签是区分大小写的.

readelf -s nasm-bin

(如果不想做任何测试直接跳转,可以使用 JMP 指令.)

我们还可以把一个标签变成一个函数(procedures),

section .data
section .bss
section .text

global _start
_start:
        nop
        mov eax, 5
        call DoMore
        mov eax, 1,
        mov ebx, 0
        int 80H

DoMore:
        dec eax
        jnz DoMore
        ret

上面的例子中的 DoMore 就变成一个函数了, 可以使用 CALL 指令进行调用.

在这个例子中, 是在 _start 里面调用 DoMore 的, 所以 _start 被叫做 DoMore 的调用者(caller), DoMore 被叫做被调用者(callee).

一个函数的结构要有以下这些点:

• 必须以标签开始,标签的名字就是函数的名字;

• 函数内部必须至少有一个 RET 指令,这个指令是作为函数的"出口",

  在有多个 RET 指令情况下,使用哪个 RET 取决于条件跳转;

• 函数可以通过使用 CALL 调用另外一个函数;

  
  

  还有一个点要注意: 函数 DoMore 定义在了 sys_exit 这个退出程序的系统调用之后.

  这是因为 CPU 会从上到下逐条执行指令,如果定义在 sys_exit 之前,

  哪怕没有 call DoMore 指令的存在,函数 DoMore 也是可以执行,

  这跟高级语言那种"只会在被调用才执行"的函数不一样,为此才把函数定义在 sys_exit 之后.

  函数对应的标签是一个地址,因此调用函数实际上就是跳转到函数的地址上,这就是高级语言函数调用的真相.

  
  

  你可能很好奇: 如何在函数内部进行内部跳转呢?

  毕竟跳转只能依靠条件跳转指令,而这些指令又依靠标签,但是函数就是以标签开头的,那在函数内部的标签不就是另外一个函数吗?

  NASM 提供一种标签叫做局部标签(local labels),它们是以句号(.)开头的标签;没有以句号开头的标签都叫做全局标签(global labels).

  上面的 _start 和 DoMore 就是全局标签.

  我们把上面的例子改成如下:

  section .data
  section .bss
  section .text
  
  global _start
  _start:
          nop
          mov eax, 5
          call DoMore
          mov eax, 1,
          mov ebx, 0
          int 80H
  
  DoMore:
          cmp eax, 3
          jz .exit1
          sub eax, 1
          jnz DoMore
          ret
  
  .exit1: ret
  

  在 EAX 减小的过程中,如果 EAX 的值等于 3,那么就直接进入 .exit1 进行退出,

  CMP 指令是比较两个值的大小,如果目的操作数等于源操作数,那么 ZF 设置为 1, JZ 就是检查 ZF 是否为 1.

  局部标签是属于它前面所遇到的第一个全局标签的,所以 .exit 是属于 DoMore 的,而不是 _start 的.

  NASM 支持从一个全局标签里面跳转到另外一个全局标签的局部标签上,我们把上面的例子再改一下,

  把 .exit1 定义为 OutSide 的局部标签,从 DoMore 跳转到 OutSide 的 .exit 上,

  section .data
  section .bss
  section .text
  
  global _start
  _start:
          nop
          mov eax, 5
          call DoMore
          mov eax, 1,
          mov ebx, 0
          int 80H
  
  DoMore:
          cmp eax, 3
          jz OutSide.exit1
          sub eax, 1
          jnz DoMore
          ret
  
  OutSide:
  .exit1: ret
  

  但是这样很容易因在代码量大的时候导致逻辑混乱而出 bugs,因此不建议这么做.

  此外开发时多要遵守一个原则: 一个全局标签尽量不要有太多局部标签,一个局部标签的区域应该尽量简短.

  关于函数的细节还有很多没有提到,这里先有个印象,后面会继续补充细节.

  通常情况下, 目标文件会记录下标签的信息, 可以使用 readelf 命令读取出来,

  假设编译出来的可执行文件名字叫 nasm-bin, 那么:

  readelf -s nasm-bin
  # output:
  # Symbol table '.symtab' contains 9 entries:
  # Num:    Value          Size Type    Bind   Vis      Ndx Name
  # 0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
  # 1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS main.asm
  # 2: 0000000000401017     0 NOTYPE  LOCAL  DEFAULT    1 DoMore
  # 3: 0000000000401022     0 NOTYPE  LOCAL  DEFAULT    1 OutSide
  # 4: 0000000000401022     0 NOTYPE  LOCAL  DEFAULT    1 OutSide.exit1
  # 5: 0000000000401000     0 NOTYPE  GLOBAL DEFAULT    1 _start
  # 6: 0000000000402000     0 NOTYPE  GLOBAL DEFAULT    1 __bss_start
  # 7: 0000000000402000     0 NOTYPE  GLOBAL DEFAULT    1 _edata
  # 8: 0000000000402000     0 NOTYPE  GLOBAL DEFAULT    1 _end
  

  除了汇编码定义的那些标签外, 还有一些额外的标签.

  如你所见, 局部标签会以 [GLOBAL-LABEL].[LOCAL-LABEL] 这种方式记录,

  有趣的一点是, NASM 其实并不要求局部标签之前一定要有全局标签, 不过这不意味着这种局部标签不属于某个全局标签,

  实际上它们是属于汇编码里面最后的那个全局标签.

  我们把前面的那段汇编码改成如下:

  section .data
  section .bss
  section .text
  
  .hello:
  
  global _start
  _start:
          nop
          mov eax, 5
          call DoMore
          mov eax, 1,
          mov ebx, 0
          int 80H
  
  DoMore:
          cmp eax, 3
          jz OutSide.exit1
          sub eax, 1
          jnz DoMore
          ret
  
  OutSide:
  .exit1: ret
  

  它的标签信息如下:

  # Symbol table '.symtab' contains 10 entries:
  # Num:    Value          Size Type    Bind   Vis      Ndx Name
  # 0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
  # 1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS main.asm
  # 2: 0000000000401000     0 NOTYPE  LOCAL  DEFAULT    1 OutSide.hello
  # 3: 0000000000401017     0 NOTYPE  LOCAL  DEFAULT    1 DoMore
  # 4: 0000000000401022     0 NOTYPE  LOCAL  DEFAULT    1 OutSide
  # 5: 0000000000401022     0 NOTYPE  LOCAL  DEFAULT    1 OutSide.exit1
  # 6: 0000000000401000     0 NOTYPE  GLOBAL DEFAULT    1 _start
  # 7: 0000000000402000     0 NOTYPE  GLOBAL DEFAULT    1 __bss_start
  # 8: 0000000000402000     0 NOTYPE  GLOBAL DEFAULT    1 _edata
  # 9: 0000000000402000     0 NOTYPE  GLOBAL DEFAULT    1 _end
  

  可以看到 .hello 这个局部标签属于汇编码里面最后的一个全局标签 OutSide.

  
  

  有符号和无符号值

  有符号值就是我们说的负数,无符号值就是正数,我们说的符号就是值正号和负号.

  想要明白两者的差别,就需要明白 CPU 把符号(sign)存放在哪里.

  其实正负号是储存在数字的二进制表示的最高位上,该最高位叫做符号位(sign bit),

  如果符号位的值是 1,那么就表示该数字是负数;如果是 0 就表示正数.

  然而一个"二进制表示"既然可以是一个正数,也可以是一个负数,这取决于开发人员怎么看待它.

  比如 10101111 可以表示一个有符号值 -81,也可以表示一个无符号值 175.

  但这不是说直接更改最高位就能改变正负号了, 就拿 42 的 8 位二进制表示 00101010 来说,就不可能直接改最高位就能得到 -42 的.

  汇编语言里面是用二的补码(two's complement)来处理负数的,在计算机里面,找到某数的负数,具体操作是把一个二进制数字里的原来的 1 变成 0,原来的 0 变成 1,然后加 1.

  补码的概念实际上来源于模运算,比如在时钟里面往顺时针方向(加)把指针拨4小时的刻度和往逆时针方向(减)拨8个小时的刻度最终达到的位置时一样的,

  而 4 和 8 相加刚好满足一个周期(模) 12.

  因此 -42 的二进制表示应该是 11010110.关于二的补码的详细内容就不展开了,可以看这里.

  幸运的是有一条 NEG 指令可以帮助直接计算一个数的的负数.

  对于 8 位二进制表示来说,如果要表示有符号数,那么能够表示的数字范围就是 -128(10000000) 到 127(01111111).

  下面是常见不同大小(指位数)的数值大小.

  

  Figure 37: 常见的范围

  处理有符号值会有一个问题: 如何处理不同位数的有符号值.符号位是处于最高位的,这就是问题所在.

  当把一个有符号的值移动到一个更大寄存器或者内存地址,会发生什么情况呢?

  (具体做法在前面讲寄存器数据的时候就讲过了,不再说了)

  比如当我们要把 8 位大小的有符号值 -42 复制到 32 位的寄存器上, 原本的符号位就不再是符号位了.

  mov al, -42
  mov ebx, eax
  

  这个时候 EAX 和 EBX 的值就是 214 了,可以通过调试器来确认这一个事实.

  针对这个问题, x86 CPU 提供了 MOVSX (Move with Sign Extension)指令来解决这个问题,

  mov al, -42
  movsx ebx, al
  

  EBX 现在的值就是 -42, EAX 依然是 214.

  

  Figure 38: MOVSX 指令

  这图是 MOVSX 指令的用法,可以看到上面是用了一些 r16, r/m16 这样的标记,这些标记在很多指令参考文档都有用,因此这里就稍微总结一下.

  r 是寄存器(register)的首个字母,表示寄存器数据, 但是不包括段寄存器的数据,

  段寄存器有专门的表示: sr 表示,它是 segment registers 的缩写,

  后面的数字表示位数,所以 r16 就表示 16 位寄存器, sr 没有后缀数字;

  m 是内存(memory)的首个字母,表示内存数据的意思,后面也有数字后缀; r/m 就表示是寄存器数据或内存数据.

  除了上面的这些,还有 i 表示立即数,后面也有后缀数字表示大小,最后还有 d 是位移(displacement)的首个字母,后面也跟着后缀数字.

  
  

  隐式操作数

  不是所有指令都是像 MOV 那样有一个目的操作数和源操作数的使用方式,它直接告诉你作用于哪些寄存器或内存地址.

  而有些指令则不是,比如对无符号数做乘法的 MUL 指令: 把两个乘数(factors)相乘后得到一个乘积(product),但它的用法就只接受一个操作数,

  

  Figure 39: MUL 指令用法

  我们把这个需要开发人员提供的操作书叫做显式操作数(explicit operand),实际上 MUL 还需要多一个操作数,

  而这个操作数的选择是 MUL 定义好的,无需开发人员提供,这种操作数就叫做隐式操作数(implicit operand).

  为什么要这么设计呢?因为两个乘数的乘法结果可以是比任意一个乘数大得多,不可能尊从"把指令产生的值储存到目的操作数上"的规范,

  乘法运算的这个问题对于所有计算机架构都是存在的,解决思路也很简单,主要是利用了一个规则:

  两个乘数的二进制位数分别是 \(m\) 和 \(n\),乘积的二进制位数是 \(p\), \(p \le 2 \times max(m,n)\).

  比如可以用 8 位表示的 255, \(255 \times 255\) 的乘积就是需要用 16 位来表示的.

  因此,你可以发现 MUL 用来储存乘积的操作数的位数大小必须是显式操作数位数大小的两倍,(用于储存乘数的两个操作数的位数是一样的.)

  当一个寄存器不够时,就用两个寄存器储存乘积,拿 r/m16 的来说,乘积的二进制中的高位 16 位储存在 DX 上,低位 16 位储存在 AX 上,

  比如 02A456Fh, 02Ah 会被储存在 DX 上,而 456Fh 被储存在 AX 上.

  而进行除法运算的 DIV 指令就没这个问题.

  

  Figure 40: DIV 指令用法

  最后这里给出 Intel 以及 AMD 的指令集文档, 实际上开发的时候尽量根据自己电脑的 CPU 来选择.

前面有提到过栈(stack)的相关概念,重复的就不赘述了,这里稍微补充一下它在 x86 里面是什么样的.

对于 x86 硬件而言它是一套储存机制,同时也是所有计算的一个关键概念.

栈从 1950s 开始就成为计算机中不可分割的一部分,但是它不像寄存器那样作为硬件出现在 CPU 里面,而是作为一个抽象概念出现在内存上.

在 x86 计算机中,栈在内存里是上下颠倒,栈顶在内存低位,栈底在内存高位.

栈是往低位空闲内存进行增长的,需要用 ESP 寄存器来记录栈顶的内存地址, ESP 有时候会被叫做栈指针(stack pointer).

在运行时, C 程序会在会在这块空闲内存上划出一个叫堆(heap)的区域,用来为变量分配空间,汇编程序也可以这么做,只是实现起来比较麻烦.

程序在开始运行时,栈并不是完全空的,里面会有些有用的东西,之后补充.

一般来说很难出现栈增长碰撞到 .bss/.data/.text 部分,如果真的发生了, Linux 会发出一个段错误(segmentation fault)并且终止程序.

栈支持 PUSH 和 POP 操作,那么就必定有相关的指令.

PUSH 操作的相关指令有 PUSH, PUSHF, PUSHFD, PUSHA 和 PUSHAD.

PUSH 指令可以把一个16位/32位大小的寄存器/内存值压进栈, 但是, 在64位下 PUSH 指令只能接收16位/64位大小的寄存器,

286 以后的 CPU 甚至能支持把立即数压进栈,如果是32位 CPU, PUSH 的每个立即数就占4个字节,64位的占8个字节,

后面栈相关的指令同理,就不重复提了,

PUSH 实际上只是把栈指针寄存器减去了压进数据的大小,并且把栈指针寄存器的值作为写入数据的地址,

比如压进的数据大小是 N 个字节,那么栈指针寄存器就减去 N,把栈指针寄存器作为地址,在这个地址上写入数据;

PUSHF 指令把16位的标志寄存器 FLAGS 压进栈, PUSHFD 则是把32位标志寄存器 EFLAGS 压进栈;

PUSHA 指令把8个16位的通用寄存器, AX, CX, DX, BX, SP, BP, SI 和 DI 依次压进栈,

PUSHAD 指令把8个32位的通用寄存器, EAX, ECX, EDX, EBX, ESP, EBP, ESI 和 EDI 依次压进栈.

其中 PUSHF/PUSHFD 和 PUSHA/PUSHAD 是不支持操作数的.

我们从 PUSH 指令入手,当使用 PUSH 把一个16位寄存器上的内容压进栈时,因为我们采用的内存是一个内存地址储存一个字节的内容, 16位寄存器的内容大小就是2个字节,所以 ESP 的值需要减少 2;

如果 PUSH 的操作数是一个32位寄存器,那么 ESP 的值就要减少 4.

POP 操作差不多就是 PUSH 操作的逆过程了,相关指令有 POP, POPF, POPFD, POPA 和 POPAD.

POP 指令根据操作数大小来让栈顶弹出对应个数的字节,比如操作数是16位寄存器,那么就弹出2个字节,如果是32位寄存器,那么就弹出4个字节,

实际上 POP 指令就是先把栈顶的数据复制到操作数上,然后把栈指针寄存器的值加上数据的大小,这样就能读取上一个被压进的数据,看上出去栈顶的数据就被"弹出"了,

实际上数据还在的,如果这个时候 PUSH 了一个相同大小的数据,那么刚才的数据就会被覆盖掉;

POPF 指令让栈顶的2个字节弹出并且储存到标志寄存器 Flags 中;

POPFD 指令让栈顶的4个字节弹出并且储存到标志寄存器 EFlags 中;

POPA 指令让栈顶的16个字节弹出,并且把其中的14个字节依次储存到 DI, SI, BP, BX, DX, CX, AX 7个通用寄存器上, SP 对应的2个字节被无视;

POPAD 指令让栈顶的32个字节弹出,并且把其中的14个字节依次储存到 EDI, ESI, EBP, EBX, EDX, ECX, EAX 7个通用寄存器上, ESP 对应的4个字节被无视.

来通过这几个指令看栈如何工作的,

push ax
push bx
push cx
pop dx

我们在前面都了解到自从保护模式出来后,操作系统都不允许应用程序直接访问硬件资源,只能通过操作系统来代劳.

int 80h 这句指令就是告诉 Linux 调用系统资源.

INT 指令的全称叫做 interrupt,这涉及了一个叫做软中断(software interrupt)的概念,它是实现"引用程序只能通过操作系统提供的方式来调用硬件资源"的关键手段,名字来源于一个叫做硬中断(hardware interrupt)的概念,稍后会介绍.

Linux 采用 kernel 的设计是为了禁止应用程序直接访问操作系统,被恶意软件接恶意破坏,这在前面就说过了;

然而这样就引发了另外一个问题, Linux 把东西藏了起来,虽然说它提供了一些可调用指令,但是指令在内存上的位置会因为系统的升级/修复等活动发生改变,那么用应用程序又是如何知道想要调用的指令在哪个位置上呢?

事实上,应用程序不需要知道这些也可以正确地调用到指令,人们把解决这个问题的东西叫做内核服务调用门(kernel services call gate),它就是通过 x86 的软中断实现的.

在 x86 内存中,从0开始的1024个字节是被保留来存放“特别数据"的,这1024个字节是一张特别的查找表(lookup table),

每4个字节存放一个"特别数据",就是说可以存放256个"特别数据"/条目.

这张表叫做中断向量表(interrupt vector table),这个表上每一个条目的 地址/编号 叫做中断向量(interrupt vector).

所存放的"特别数据"实际上是系统提供的可调用指令的地址,4个字节32位刚好可以表示内存上的任意一个地址,

每次启动机器时, Linux 和 BIOS 都会往表里面填充可调用指令的地址,哪个中断向量上存放哪个可调用指令的地址都是操作系统规定好的,即便操作系统进行了更新,这点也是不会变的;

想调用哪个可调用指令,只要知道哪个中断向量储存了它的地址就可以.

回到 int 80h 上, INT 的操作数就是中断向量,这条指令实际上是先从 80h 上找到可调用指令的地址,然后找到并且执行对应指令.

80h 指向的实际上是一个叫做服务调度器(services dispatcher),可以通过它来调用到差不多200多个 Linux 内核可调用指令.

一般来说程序是不需要直接访问中断向量表的,况且保护模式会限制这么做,而服务调度器会帮助开发者在无须了解中断向量表的情况下访问到对应指令.

此外, int 80h 还会把下一条指令的地址压进栈,我们把这个地址叫做返回地址, CPU 在执行完 int 80h 后返回到这个地址上.

可以看到服务调度器在执行完指令以后会执行一个 IRET 的指令,它的全称是 interrupt return,

作用就是把 INT 压进栈的地址弹出来,并且根据这个地址进行跳转.

软中断的名字来源于硬中断,电脑内置的电气系统让电路板给 CPU 发送电信号, CPU 上有种特殊的金属针(pin)会被电路板上的设备改变电压,这就是发送电信号的本质.

一个电信号叫做一个硬中断(hardware interrupt),就像软中断一样,硬中断被编号了,是中断向量表的条目,这张表上面存放的数据叫做中断服务程序(interrupt service routine, ISR)的地址.

ISR 会执行一些与发送电信号的硬件有关的事情.

和软中断不同之处在于硬中断不使用 INT 指令进行触发,并且软中断的向量表是软件的一部分;

当 CPU 接收到硬中断后, CPU 会把返回地址压进栈里,在 ISR 执行完毕后会通过 IRET 指令返回,就像软中断所做的一样.

位映射(bit mapping)是汇编语言里广泛使用的一项技术,它为字节的每一个位(bit)赋予特殊含义,榨干内存的最后一个位来节省空间.

按照不成文的规定,在汇编语言里面,会给位序列的每一位进行编号,这叫做位编号(bit numbering).

从最低有效位(least-significant bit, LSB)开始,第一位编码为0.

日常使用的相关指令有这些,针对逻辑运算的指令叫做位逻辑指令(bitwise logical instructions),有 AND, OR, XOR 以及 NOT;

用于移位或者旋转位的指令有 ROL, ROR, RCL, RCR, SHL 和 SHR.

汇编语言把一个1位(a 1 bit)看作一个 True,把一个0位(a 0 bit)看作一个 False.

逻辑运算的概念就不在赘述了,贴几张真值表(truth table)就算了.

前面提到的几个位逻辑指令里面, AND 用的是最多的,它的一个主要用法就是位掩码(bit mask),作用是把无用的位都设置为0位.

还有一个比较有意思的是 XOR 指令,它的全称是 exclusive or,意思是相同的为 False, 不同的为 True,

它可以用来做很多事情,在以前它经常用来快速给寄存器清零,比如给 AL 清零.

对于位移操作,先来看看 SHL 和 SHR 指令,它们分别是把位往左和往右移 N 位,它们的用法大概是 SHR/SHL r/m8/16/32 i8/16/3 这个样子.

在数学上,把一个数 M 往左移 N 位的结果就是 \(M \times 2^{N}\), 而往右移动 N 位的结果就是 \(M \times 2^{-N}\).

然而在汇编是有位数限制的,比如,对 AL: 0000 1000 移动 N 位,那么这个 N 的值最大应该是8,这是因为 AL 只有 8 位.

假设这个 N 为 2,那么往左移的话就是在 LSB 后面加多两个0,再去掉 MSB 的两位,结果就是 0010 0000, 去掉的位就是溢出的;

如果是往右移,那么就是先在 MSB 前面加上两个0,在去掉 LSB 的两位,结果就是 0000 0010.

前面提到过位移操作也会能改变 CF, 只要最后溢出的一位是1,那么 CF 就会被设置成1, 这其实和前面提到过的进位或借位说法是对应的,可能这还更好理解一点.

来看几个例子,

假设对 AL: 1000 0000 进行左移1位,因为溢出的是 MSB,而它是1,那么 CF 就被设置为1;如果是左移2位,因为溢出的是 10,先溢出的是1,然后是0,所以 CF 就被清零.

假设对 AL: 0000 0001 进行右移1位,因为溢出的是 LSB,而它是1,那么 CF 就被设置为1;同理如果是右移2位,溢出的是 01,先溢出的是1,然后是0,所以 CF 就被清空0.

SHR/SHL 都会因为溢出而失去原来储存的部分信息,那么有没有办法可以避免这个问题呢?答案是有的,那就是旋转(rotate)命令.

首先介绍 ROL 和 ROR 这两个命令,它们的全称分别是 Rotate Left 以及 Rotate Right.

比如,我们对 AL 左旋转1位,变化过程是这样的,

简单来说, ROL 指令就是把 MSB 的 N 位移动到 LSB 后面; ROR 指令同理,只不过它是把 LSB 的 N 位移动到 MSB 的前面.

这两个指令是不会改变 CF 的值的,因为无论它们如何操作都不会发生溢出.

RCL 和 RCR 同样是旋转指令的一种,跟 ROL 以及 ROR 相比,它们需要借助 CF 进行旋转;

它们的全称分别是 Rotate Carray Left 和 Rotate Carray Right,来看一下 RCL 如何对 AL 进行旋转的,

简单来说就是 RCL 先把 CF 插入到到 LSB 后面,然后把溢出的 MSB 的值储存到 CF 上,如果是旋转 N 位,那么就把这个过程循环 N 次;

RCR 同样道理,只是先把 CF 插入到 MSB 前面,然后把溢出的 LSB 的值储存到 CF 上而已.

跳转分无条件跳转(unconditional jumps)和条件跳转(conditional jumps).

我们很熟悉的一个无条件跳转的指令就是 JMP,只要指定了跳转目标就一定会跳转.

而条件跳转是需要符合条件才会发生跳转的,当标志寄存器的某一个 flag,甚至几个 flags 符合条件才能跳转,

否则直接执行下一条指令.

比如 DEC 指令,对操作数减1,执行过后还会看操作数的值是否为0,如果为0就把 ZF 标志设置为1.

如果我们要在操作数到0时进行跳转,那么可以用 JZ(Jump if Zero) 指令来测试 ZF 是否为1,如果 ZF 是1就会进行跳转.

JZ 就是一个条件跳转指令,和条件跳转指令配合使用最多的就是 CMP 指令: CMP op1, op2.

CMP 会先计算出结果 \(result = op1 - op2\),然后根据 result 来按照情况设置 OF, SF, ZF, AF, PF 以及 CF 标志.

基本上条件跳转的判断就是 \(>\), \(<\), \(\ge\), \(\le\), \(=\) 以及它们的取反(not)变种这几种,

由于 x86 还分有符号和无符号运算,因此最终一共有 \(5 \times 2 \times 2 = 20\) 个条件跳转指令.

这些指令的助记符会通过 above 和 below 来用于无符号值之间的比较, greater than 和 less than 用于有符号值之间的比较.

还有提供 TEST 和 BT 这样的指令来检测位的值.

首先是 TEST op bit-mask, 用来检查某些位是不是设置为了1,如果不是,那么 ZF 就变为1.

比如 test ax, 08h 就是测试 ax 第3位是否设置为1, 08h 在二进制就是 00000100.

其实 test 指令很简单,它其实就是先用 AND 指令进行运算,不过这个运算不会改变目的寄存器的值,

如果运算结果为0,那就证明所有被测试的位没有设置为0,这个时候 ZF 就会被设置为1.

BT op bit-number, 用来检操作数某一位是的值是0还是1,其实 BT 指令就只是把某一位的值复制到 CF 上,

然后可以使用 JC 或者 JNC 来判断跳转.比如 bt eax, 4 就是测试 EAX 的第4位的值.

其实我们在前面就见到过表(table),字符串就是表(table)的一种.

DB 指令的作用也可以理解为定义一张表,表的每个元素的大小为1个字节,第一个元素的地址作为整个表的地址.

根据维度划分,表主要分一维表和一维以上的多维表.

前面的 EatMsg 就是一张一维表;

在汇编语言里面,实际上是只有一维表,没有二维表(two-dimensional table)以及更高维度的表.

不过,我们可以把一维表定义为一个二维表,或者更高维度的表.

比如,二维表满足这些特性: 表的元素本身是一张表,称之为子表(subtable),子表也包含了一些元素.

那么只要把一维表"设计"成满足这样访问的方式即可:

可以根据表获取到任意的一个子表地址,再可以根据子表的地址获取到子表里任意的一个元素.

比如,

SECTION .data
DDTable:
        db 10, 12, 14, 16
        db 20, 22, 24, 26
        db 30, 32, 34, 36

NASM 可以像上面那样把一个表用 db 分成几行来定义, NASM 会把几行定义合并在一起.

上面的 DDTable 是一个有12个元素的表,可以把每一行看作一个子表,每个子表有4个元素.

注意,这里不能这么写:

SECTION .data
        DDTable
        db 10, 12, 14, 16
        db 20, 22, 24, 26
        db 30, 32, 34, 36

如果定义一个变量不带冒号(:),并且变量单独占一行,那么这样的变量叫做孤儿标签(orphan labels)

假设现在需要取第2个子表的最后一个元素,那么就要这么做,

SECTION .text
GLOBAL _start
_start:
        mov ecx, 1
        mov al, byte [DDTable+ecx*4+3]

或着这样,用一张表储存内存地址,而这些内存地址是其它表的地址,在32位保护模式下,储存一个内存地址需要32位,因此表的一个元素需要用4个字节储存,

我们把上面的例子改一下,

SECTION .data
SubTable1: db 10, 12, 14, 16
SubTable2: db 20, 22, 24, 26
SubTable3: db 30, 32, 34, 36
DDTable: dd SubTable1, SubTable2, SubTable3

section .text
global _start
_start:
        mov ecx, 1
        mov eax, [DDTable+ecx*4]
        mov bl, byte [eax+3]

DD 指令是 "Define Double" 的意思,用两个字(word)储存一个员元素,也就是4个字节.

虽然说一个元素用4个字节的空间来储存,但是内存寻址依然要遵守"一个内存地址只能存放一个字节的数据"的原则,

所以上面查找子表的地址依然需要 [DDTable+ecx*4] 这样每4个字节为子表的地址.

在学习标签时稍微介绍了一下函数的基本定义以及使用, 如果你已经接触过一些高级语言, 你会发现还有很多东西没有介绍到,

比如, 如何给函数定义参数以及如何传递参数, 如何在函数内定义局部变量, 如何递归等等, 此外还有一些高级语言里面没有体现到的细节.

一旦涉及到函数, 那么就要提一个概念: 全局数据(global data)和局部数据(local data).

所谓全局数据就是在程序的任何地方都可以访问得到的数据.

像前面的简单例子 eatsyscall 中, 在 .data 和 .bss 区域定义的数据就是全局数据, 如果一个程序分成了好个文件,那么全局数据的区分就更加复杂了, 之后会了解库(library)这个概念.

而局部数据就是数据只能在函数内或库内进行访问, 然而, 局部数据并没法像 .data 和 .bss 里面数据那样定义.

寄存器可以储存数据, 然而如果数据个数是不定的, 而寄存器的数量又有限, 那么该如何储存这么多数据呢?

毫无疑问, 需要靠内存来储存数据.

对于函数来说, 局部数据只有在函数被调用的时候才会可以访问, 那么只要让这些数据在函数被调用的时候储存在内存上, 函数结束后把这些数据清空掉, 而栈正好符合这要求.

举个实际例子, 有一个叫做 Add1 的函数, 它的作用是计算 \(5 + 6\) 等于多少, 计算完毕就结束程序,

section .data
section .bss
section .text
global _start
_start:
        mov eax, 1
        mov ebx, 0
        call Add1
        int 80h

Add1:
        mov eax, 5
        mov ebx, 6
        add eax, ebx
        ret

这个程序有一个问题, 那就是调用完 Add1 后, eax 变成11, ebx 变成6, eax 和 ebx 上的值被覆盖了, 因此最后的 int 80h 没有调用到 sys_exit().

这 通常 不是我们想要的, 想要在不影响寄存器的前提下解决这种问题, 通常需要用到栈, 按照这个思路把程序改一下,

section .data
section .bss
section .text
global _start
_start:
        mov eax, 1
        mov ebx, 0
        push rax
        push rbx
        call Add1
        pop rbx
        pop rax
        int 80h

Add1:
        mov eax, 5
        mov ebx, 6
        add eax, ebx
        ret

需要注意一下的是, 这个是64位程序, PUSH 和 POP 指令的操作数不能是32位寄存器, 而 rax 和 rbx 分别是 eax 和 ebx 的 64 位拓展.

在调用函数之前把需要使用到的寄存器上的数据用栈"备份"下来, 在函数调用结束后把数据”恢复“到原来的寄存器上.

也就是在调用函数前用 PUSH* 指令把数据压进入栈, 调用结束后用 POP* 指令把数据还原好, 顺便把栈上不需要的数据清空, 也就是 eax 的 1 和 ebx 的 0.

这样在函数调用结束, eax 和 ebx 的值还分别是原来的 1 和 0 ,这样程序就可以在计算完后正常退出程序.

要注意,以什么顺序把寄存器的值 PUSH 进去的,就得按照 相反 顺序把值 POP 出来, 其实这一点只要能够理解栈的工作方式都能明白.

有时候 PUSH 和 POP 操作可以在函数内完成,在介绍递归时在演示.

Add1 里面的 eax 和 ebx 上的数据就是前面提到的局部数据了.

这个 Add1 实际上没什么用处,因为它只能计算 \(5 + 6\) 这个加法运算, 没有发挥到函数的真正作用: 接受参数并进行计算, 最后返回计算结果.

再把程序改一下,让 Add1 更加灵活,

section .data
section .bss
section .text
global _start
_start:
        mov eax, 1
        mov ebx, 0
        push rax
        push rbx
        mov eax, 3
        mov ebx, 4
        call Add1
        pop rbx
        pop rax
        int 80h

Add1:
        add eax, ebx
        ret

函数内部决定了它使用哪些寄存器, 比如这个例子使用了 eax 和 ebx,

那么给它传参数就是先给这两个寄存器设置好值, 再调用函数, 这就是大部分高级语言给函数传参数的真相.

没有规定一定要用什么通用寄存器来进行传递参数, 甚至可以不用寄存器而是使用内存(栈)来传递参数.

然而在没有规范的情况下, 调用别人编写的函数会变得很麻烦, 在后面 调用C库的函数 会聊到规范的问题.

最后再来一个递归的例子作为结束,顺便介绍一下 call 指令和跳转指令的区别.

这一个例子里面的 Acc 函数就是一个递归函数,这个程序会通过它进行 \(1+2+3+4\) 运算,

section .data
section .bss
section .text
global _start
_start:
        mov eax, 1
        mov ebx, 0
        push rax
        push rbx
        mov eax, 4
        mov ebx, 0
        call Acc
        pop rbx
        pop rax
        int 80h

Acc:
        cmp eax, 0
        jle .exit
        add ebx, eax
        dec eax
        push rax
        push rbx
        call Acc
        pop rbx
        pop rax
        jmp .exit
.exit:
        ret

可以看到 Acc 里面使用了 call 指令调用 Acc 自己, 并且在调用之前还需要按照"备份和还原寄存器”的老套路.

这个递归是最简单的了,可以很简单地把它改成循环,

section .data
section .bss
section .text
global _start
_start:
        mov eax, 1
        mov ebx, 0
        push rax
        push rbx
        mov eax, 4
        mov ebx, 0
        call Acc
        pop rbx
        pop rax
        int 80h

Acc:
        cmp eax, 0
        jle .exit
        add ebx, eax
        dec eax
        jmp Acc
.exit:
        ret

这两个都能正确进行计算,然而两者差别很大,这也就是 CALL 指令和跳转指令之间地区别.

CALL 指令会先把当前位置的下一条指令地址压(PUSH)进栈里面, 然后再跳转(JMP)到对应标签的地址.

比如在 _start 标签里面的 call Acc 在执行时候, 会把 pop rbx 指令的地址压进到栈里面, 然后跳转到 Acc 标签地址上.

而 jmp Acc 是直接跳转到 Acc 标签上.这就是 Call 指令和跳转指令的差别.

也正因为如此, CALL 指令要配合 RET 指令使用, RET 的作用就是把 CALL 压进去的"下一条指令的地址"弹出来,并且返回(跳转回)到这个地址上,

这样就完成了一趟函数调用的"旅程".

RET 指令和跳转指令也有一些共同点, 那就是跳转的距离, 它是指跳转指令(jump instruction)到跳转目标(jump target)两个内存地址之间的距离.

在条件跳转指令(也就是 JMP 以外的跳转指令)要跳转到一个很远的距离时,汇编器会出现这样的错误:

"error: short jump is out of range".

NASM 可以根据不同情况下的同一个条件跳转指令产生不同的操作码(opcode), 这个不同情况就是指定的跳转距离.

也就是根据跳转距离可以划分得到不同的跳转类型,距离一共有3种: short, near 和 far,这个是从小到大排序的.

short 是指跳转距离在127个字节内; near 是指跳转距离在大于127字节而仍然在当前代码段内,因为32位保护模式下只有一个代码段,所以保护模式下规定最大可达 2GB;

far 则是指跳转距离完全跳出了当前代码段的范围, far jump 其实很少用得到,无论是在 DOS 时代还是32位保护模式时代,因此不会讲这个.

short jump 和 near jump 所产生的操作码是不一样的, short jump 的操作码都是2个字节大小的,而 near jump 的操作码是4个或者6个字节大小的,这取决于各种因素.

short jump 的操作码都是效率很比较高的,这种叫做 compact code/fast code.

NASM 默认生成 short jump 的操作码,除非指定生成 near jump.

jne SomeLbl      ; Short jump
jne near SomeLbl ; Near jump

通常出现 "short jump out of range" 错误是因为把用来某个标签放到程序的最后, 然后在不同地方跳转到这个标签, 而程序又十分大而导致的.

解决这个问题很简单, 就是在目标标签前面加一个 NEAR 关键字.

RET 指令也分不同距离进行返回,不过它只有两种: near return 和 far return,分别对应指令 RETN 和 RETF.

除开必要情况,通常使用 RET 指令就可以了,在汇编时, NASM 会自动根据情况对 RET 指令生成 RETN 和 REFF 对应的操作码.

RET 有一个可选操作数, 类型为 i8, 用来指定在函数返回时指定释放栈上 N 个字节的数据, 具体就是把栈指针 ESP 的值增加 N,

支持这个操作数是因为有些 CPU 支持把立即数压进栈, 清空这种数据的唯一办法只能让栈指针寄存器(ESP)增加对应数据的大小.

前面有提到过库的这个概念,提到库第一时间想到的就是"把一个程序分成多个模块",生成程序的时候再把模块链接起来.

链接方式有两种: 静态链接(static linking)和动态链接(dynamic linking).

静态链接就是把所有模块文件全部"合并"成一个可执行文件,可执行文件的大小基本上就是模块文件大小的总和;

动态链接则是把多个模块文件"像连线一样关联"到一起,生成的可执行文件的大小比静态链接得到的可执行文件的大小要小.

动态链接的模块文件就像可替换的零件一样,每次只要模块文件有更新,无需重新链接生成可执行文件,只要替换需要更新的模块文件就好;

而静态链接一旦有模块文件要更新,那么重新链接生成整个可执行文件.

一般为了方便发布程序,都采用动态链接的方式生成程序;简单的程序一般用静态链接生成.

我们把上一个节的示例程序作为例子,把循环版的 Acc 单独拆出来作为一个模块 mathlib.asm,调用 Acc 的模块叫做 main.asm,

        ; main.asm
GLOBAL _start
EXTERN Acc

SECTION .data
SECTION .bss
SECTION .text

_start:
        mov eax, 1
        mov ebx, 0
        push rax
        ; push rbx
        mov eax, 4
        mov ebx, 0
        call Acc
        ; pop rbx
        pop rax
        int 80h

        ; mathlib.asm
GLOBAL Acc:function
SECTION .data
SECTION .bss
SECTION .text

Acc:    cmp eax, 0
        jle .exit
        add ebx, eax
        dec eax
        jmp Acc
.exit:  ret

这里为了方便调试,我去掉了 main.asm 里面的 rbx 的进出栈指令,整个程序会把计算结果当作返回值.

mathlib.asm 和 main.asm 的作用是不一样的, main.asm 是作为程序的入口的,而 mathlib.asm 则是作为 main.asm 一部分功能的供应方,

因此 mathlib.asm 是没有 _start 标签的,我们把没有 _start 标签的模块文件叫做库(libraries).

GLOBAL 指令的含义其实是把标签声明为可以被别的模块调用,像 GLOBAL Acc:function 就是把 Acc 标签定义成一个"接口",别的模块可以使用这个"接口",

这种由目标文件提供的接口叫做应用程序二进制接口(Application binary interface), 简称 ABI, 和 API 这概念很相似, 只是 API 是源代码和库之间的接口.

而 Acc 后面跟着的 :function 则是告诉 NASM Acc 是一个函数,这个类型声明是可选的,只是没有的话在链接时 ld 命令会有一些警告.

类型声明一共有两种: :function 和 :data, :data 类型是接口标签是一个数据,这里的数据不包括常量,并且 :data 后面还可以跟着一个大小声明,

比如, GLOBAL myData:data 4 就是告诉 NASM myData 是一个数据,它的大小为4个字节,有时候不知道数据有多大,可以让 NASM 自己计算,

GLOBAL myData:data myData.exit-myData
SECTION .data
myData: db 'Never gonna give you up', 10
.exit:

myData.exit - myData 是一条表达式,计算两个标签之前的间距.

当接口被定义好后,在调用一方的模块中,需要使用 EXTERN 指令将标签声明为外来标签,

在 main.asm 里面的 EXTERN Acc 就是告诉 NASM Acc 的定义在 main.asm 之外.

一但划分好模块就可以生成可执行文件了,假设两个模块文件是处于同一个目录下的.

先来静态链接,

main: main.o mathlib.o
        ld -o main main.o mathlib.o
main.o: main.asm
        nasm -f elf64 -g -F stabs main.asm
mathlib.o: mathlib.asm
        nasm -f elf64 -g -F stabs mathlib.asm

或者

main: main.o mathlib.a
        ld -o main main.o -l:mathlib.a -L.
main.o: main.asm
        nasm -f elf64 -g -F stabs main.asm
mathlib.a: mathlib.o
        ar rcs mathlib.a mathlib.o
mathlib.o: mathlib.asm
        nasm -f elf64 -g -F stabs mathlib.asm

./main
echo $?

echo $? 是输出上一个命令的返回码,程序没有错的话可以看到输出10.(之所以这么做是因为 gdb 貌似不能调试动态库提供的函数.)

第二个则是使用了 ar 创建了一个 mathlib.a 静态库, 一个静态库实际上就是一个由若干个 object 文件组成的集合,

如果你的目的是发布库, 那么推荐使用第二种方法.

再来 动态链接, 不过在这之前, 我们需要把 main.asm 调整一下,

        ; main.asm
GLOBAL _start
EXTERN Acc

SECTION .data
SECTION .bss
SECTION .text

_start:
        mov eax, 1
        mov ebx, 0
        push rax
        ; push rbx
        mov eax, 4
        mov ebx, 0
        call Acc wrt ..plt
        ; pop rbx
        pop rax
        int 80h

调用外部引用 Acc 时在其后面加上了 wrt ..plt 的声明, plt 的全称是程序链接表(procedure linkage table), 我们会在后面探究 ELF 文件时会对它进行学习.

目前只需要知道这是在声明 Acc 是外部模块的一个函数, 有了这个声明, NASM 让链接器在链接时生成一个表来查找 Acc 的定义(. 参考 Position-Independent Code: ELF Special Symbols and WRT).

链接时需要在生成可执行文件的一步给 ld 命令加上 -pie 选项, 所以最终的 Makefile 是这样的(参考 https://www.nasm.us/doc/nasmdo10.html#section-10.2.5):

main: main.o mathlib.so
        ld -o main main.o -pie -I/lib64/ld-linux-x86-64.so.2 -L . -rpath . -l:mathlib.so
main.o: main.asm
        nasm -f elf64 -g -F stabs main.asm
mathlib.so: mathlib.o
        ld -shared -o mathlib.so mathlib.o
mathlib.o: mathlib.asm
        nasm -f elf64 -g -F stabs mathlib.asm

如果程序没有任何问题, 那么同样返回值是10;

如果把 mathlib.so 改了个名字或者移除掉的话, main 就会运行不了,并且报错:

"./main: error while loading shared libraries: mathlib.so: cannot open shared object file: No such file or directory".

比起静态链接, 这里多了一步 mathlib.so 的编译, *.so 就是 Linux 的动态链接库的后缀, so 的全称是 shared object 的意思.

而且在最后生成可执行文件 main 时要告诉 ld 命令: math.o 文件要如何和动态库 mathlib.so 链接.

ld 命令的 -I 选项是指定用使用哪一个动态链接器, 当链接生成目标的一个引用动态库的 ELF 程序时, 可能需要手动设定一下动态链接器, Ubuntu 的64位动态链接器位于 /lib64/ld-linux-x86-64.so.2;

ld 的 -L 选项是指定在哪个目录下搜索即将链接的库文件, 由于是生成的 mathlib.so 在当前目录下, 所以这里指定了 .;

ld 的 -l 选项用来指定要链接哪个库, 它有两种语法 -l:filename 以及 -l name,

第一种是从指定路径下找到名字叫做 filename 的库文件, 第二种是从指定的搜索路径中查找名字叫 libname.a 或者 libname.so 的库文件, 我们这个例子里面用的是第一种写法;

ld 的 -rpath 选项是指定可执行程序在运行时搜索动态链接库文件的目录,也就是 main 在运行时在什么地方找 mathlib.so 文件.

当我们得到一个动态链接程序以后, 可以使用 ldd 命令来查看它链接了哪些动态库文件,

ldd main
#  结果大概如下:
#
#       linux-vdso.so.1 (0x00007fff02522000)
#       mathlib.so => ./mathlib.so (0x00007fd278704000)

ld 命令使用 -shared 选项意味着最后链接得到的是一个动态链接库.

实际上关于动态还有很多细节没说, 我把这些内容放到后面探究 ELF 文件里面去了.

函数是一种复杂管理工具(complexity-management),把程序按照一定逻辑分成多部分.

函数遵守调用(calling)和返回(returning)的规范,这是建立在 CPU 提供的 CALL 和 RET 指令的基础上的.

而宏作为另外一中复杂管理工具,是依赖于汇编器上的,而不是基于 CPU 提供的功能.

宏是一个标签,这个标签代表了一个文本行序列(sequence of text lines),而这个文本行序列的内容 可以 是一个指令序列.

当汇编器遇到一个宏标签时,汇编器会把一个宏标签替换成它所代表的文本行序列,这叫做宏展开(expanding the macro);

然后这些文本就像是出现在源代码上被进行汇编.

NASM 使用 %MACRO 和 %ENDMACRO 指令(directives)来定义宏.

图中的 WriteStr 就是一个宏标签,以 %macro 指令开头,一直到 %endmacro 指令为止就是一个宏定义.

汇编的时候,汇编器会把所有遇到的 WriteStr 标签替换成它的定义,就像图中描述的那样.

这图是一个非常简单的例子,宏也可以像函数那样支持传递参数.

假设有个程序经常调用 sys_write 来打印字符串,可是每次调用都要传入4个参数,导致很繁琐,如果只需要传入输出的字符串和字符长度两个参数就好了.

这个时候宏可以解决这个问题,我们把上面的 WriteStr 改一下来完成这个任务.

SECTION .text

GLOBAL _start

%macro WriteStr 2               ; 2 means two arguments, %1 = String address; %2 = string length
        push rax
        push rbx
        mov eax, 4
        mov ebx, 1
        mov ecx, %1              ; Put string address into ECX
        mov edx, %2              ; PUt string length into EDX
        int 80H
        pop rbx
        pop rax
%endmacro

_start:
        WriteStr Msg, MsgLen
        mov eax, 1
        mov ebx, 0
        int 80H

在定义宏时,宏标签后面可以跟一个常量 N 表示这个宏接受 N 个参数.在宏定义里面要引用第 i 个参数,需要用到 %i 这样的符号.

WriteStr 的定义里面,把第一个参数传入到 ECX 上,第二个参数传入到 EDX 上.

如果传入的参数数量比定义的要少,那么在汇编时很有 可能 会报错,这取决于如何使用未定义的参数;'

如果传入的参数数量比定义的多,那么多余的参数就会被无视.

如果宏定义里面使用了其它的宏,那么在展开时,里面的宏也会被展开.

在汇编语言里面,标签(label)一定要是唯一的,准确来说是全局标签.

因为宏本质作用是在解决代码重复的问题,是注定要出现程序的任何地方,如果宏使用了全局标签,这会出现全局标签重复的问题.

可是如果宏不能使用标签的话,那么如何实现跳转呢?其实宏有自己的局部标签,这种局部标签不会出现标签重复问题,宏局部标签是以 "%%" 符号开头的.

有一个把 buffer 里面的字符串转化位大写的程序如下,

%macro UpCase 2     ; %1 = Address of buffer; %2 = Chars in buffer
        mov edx,%1  ; Place the offset of the buffer into edx
        mov ecx,%2  ; Place the number of bytes in the buffer into ecx
        %%IsLC: cmp byte [edx+ecx-1],’a’ ; Below 'a’?
        jb %%Bump                        ; Not lowercase. Skip
        cmp byte [edx+ecx-1],’z’         ; Above 'z’?
        ja %%Bump                        ; Not lowercase. Skip
        sub byte [edx+ecx-1],20h ; Force byte in buffer to uppercase
        %%Bump: dec ecx          ; Decrement character count
        jnz %%IsLC     ; If there are more chars in the buffer, repeat
%endmacro

可以看到,里面是利用宏局部标签作为跳转目标的: %%IsLC 以及 %%Bump.

宏也可以像函数那样定义在库里面,这种库叫做宏库(macro libraries),一个宏库就是一个包含了源代码的文本而已.

函数库能够单独汇编成一个模块,引用这个模块只要链接起来就好.

可是宏库不一样,只要汇编的模块有引用宏库,那么在汇编时宏库就一定要被传入进去,如果有很多个这样的模块,那么严重影响汇编效率.

引用宏库需要使用 %INCLUDE 指令,比如行在有一个叫做 mylib.mac 的宏库,

%include "/path/to/mylib.mac"

引用时要确保路径正确,否则 NASM 不能定位到宏库文件然后产生错误,就类似这样,

xxx.asm:1: fatal: unable to open include file `mylib.mac'

宏的使用远远不止这样,具体可以看 NASM Macro.

把汇编语言创建的程序和 C 语言的函数链接起来时,得到的其实是一个混合程序了(hybrid).

为什么汇编和 C 语言两门不同的语言所编写的程序能够链接起来并且正常运行?

虽然开发程序时使用的语言不一样,但是得到的目标文件都是使用机器码,

由于都是在同一个架构同一个系统下进行汇编/编译的, 那么彼此的目标文件都是使用了同一套规则的机器码,

也就是使用了同一门语言, 在这个层面上是可以调用彼此的, 这就是基本原因.

在 Linux 上基本上所有 C 程序都是用 GCC 编译得来的, 包括 Linux 本身的大部分.

GCC 编译程序分为很多个步骤, 每个步骤都由不同工具完成, 可以说 GCC 是一个由多个工具集合而成的工具.

下面这图就是这些工具之间是怎么样的一个工作流程:

首先, GCC 会对 C 源代码(.c)进行预处理, 所谓的预处理就是对于源代码里面的宏进行展开, 得到一份展开了宏的新代码(.c),

完成这项工作的工具叫做 C preprocessor, 简称 CPP.

C 的宏展开和 NASM 的宏展开很类似, 除了语法外, 概念上都是一样的.

然后, GCC 根据展开后的代码生成一份汇编源码(.s), 这份汇编源码只能由一个叫做 GAS 的汇编器进行汇编;

之后, GAS 把这份汇编源码进行汇编得到一个模块文件(.o);

最后 ld 把模块文件链接得到一个可执行文件, 当然 GCC 会给 ld 设置了某些参数, 和我们之前链接方式是有点差别的.

GAS 支持的汇编语法是 AT&T, 和使用 INTEL 语法的 NASM 是不一样的.

不过这不是问题, 因为它们生成的模块文件都可以使用 ld 来进行链接.

假设有一份根据 NASM 语法编写的源代码叫做 callc.asm, 使用了 Linux 标准 C 库 GLIBC 的函数, 那么可以这么汇编和链接:

callc: callc.o
        gcc -no-pie callc.o -o callc
callc.o: callc.asm
        nasm -f elf64 -g -F stabs callc.asm

最后得到 callc 就是混合产物, 这个产物的结构如下:

Startup Code 和 Shutdown Code 都是 Glibc 的产物, Startup Code 里面使用了 CALL 指令调用模块 calcc.o 的 main 函数,

main 必须通过 RET 指令进行返回, CPU 继续执行 Shutdown Code,最后把控制全交还给 Linux.

然而,只保证了"彼此的目标文件使用同一门语言"还是无法保证可以它们在链接起来后能够正常运行.

在前面介绍函数时就提到过几乎所有高级语言的函数调用本质都是: 先备份好函数用到的寄存器, 然后调用函数, 在返回函数后还原寄存器.

不同语言在汇编层面上会有一些区别, 也就是具体的调用规范会不太一样, 比如某门语言的编译器在生成程序时,

规定只能用某几个寄存器来给函数传某一数据类型的参数, 别的数据类型参数就用栈来传入, 用另外某一个或者两个寄存器用来储存函数返回值等等.

人们为不同的系统定制了一份 ABI 调用规范, 哪怕是不同的编程语言, 只要它们的编译器在生成目标文件时遵守同一个调用规范, 它们的目标文件都是可以相互调用的.

C 语言编译器 GCC 在 Linux x86 上采用规范的是 System V ABI, 分 i386 和 x86-64 两个版本, 前者就是32位平台, 后者是64位平台.

i386 的规范如下:

• 调用前函数必须保留 EBX, ESP, EBP, ESI 以及 EDI 这几个寄存器的值,在函数返回后必须还原回.
• 函数的返回值要保存到 EAX 上,如果返回值超过32位,那么返回值要存放到 EDX 和 EAX 上, EAX 储存 LSB 方向的32位,高位的存放在 EDX 上.
• 传给函数的参数要以逆序(reverse order)压进栈,比如 myFunc(foo, bar, bas) 就是把 bas, bar 和 foo 三个参数依次压进栈.
• 函数自身不把压进去的参数弹出,在函数返回后必须手动把这些参数弹出来,或者直接增加 ESP 对应的偏移值(offset)来释放栈,后者更加常用更加快.
• C 程序的起点标签是 main (全小写)而不是 _start.

i386 现在基本被淘汰了, x86-64 相比而言主要做了以下改变了:

• 调用函数前必须保留 rbx, rbp, rsp, r12, r13, r14 和 r15,函数结束后需要还原它们;
• 栈帧多出了一个 red zone 内存块;

• 传递参数的方式改变了,对参数进行分类,不同类型使用不同方式传递,总得来说分标量(scalar)和矢量(vector)两大类,

  比如属于标量的整型数类型的参数从左到右依次使用通用寄存器 rdi, rsi, rdx, rcx, r8 以及 r9 传递参数,如果参数数量超过这几个寄存器的数量,那么就通过栈来传递多余的参数;

  内存类型数据使用栈来进行传递,等等,具体可以查看 System V x64 ABI 的 Parameter Passing;

• 使用 rax 和 rdx 分别作为第一和第二返回寄存器,还有一些特殊类型的数据需要使用别的寄存器来进行返回.

  rax 还有一个作用, C 语言支持一种可变参数函数(variable arguments function, varargs function),这种函数的参数数量是不固定的,需要让 rax 记录传递的参数里面有多少个矢量参数.

  总得来说, x86-64 相对 i386 的 ABI 规范的主要变化就这些,有一个点倒是没有这么改变的,那就是对栈的依赖.

  编译器本质是一个生产汇编代码的机器(robots), 这意味着编译器必须依靠暴力(brute-force)的手段来生成代码, 而这些手段大部分都依靠栈来实现.

  对于 C 程序来说, 在每次调用函数时, 编译器会为该分配一块内存区域用于存储函数相关的数据, 在函数返回后这块区域就会被销毁, 人们会把这块内存区域做栈帧(stack frame),

  叫做栈帧是因为它是栈上一个数据, 一个基本单位, 一个栈帧就是一个函数调用, 里面包含了函数各自的数据(函数的局部变量), 保证函数与函数之间的数据不会发生混乱.

  现在有一个问题就是: 如何给函数划分一块区域作为它的栈帧, 或者说怎么 建立栈帧 ?

  要确定一块内存区域只需要知道起始位置和结尾位置, 所以需要两个通用寄存器来储存这两个信息, 从而确定栈帧.

  i386 规范规定用 EBP 来储存栈帧的起始位置, ESP 储存栈帧的结尾位置, 每次往栈里面压进了数据, ESP 就会相应减少, 指向下一个栈帧.

  

  Figure 60: Stack in i386 ABI

  我们接下来会讲解在汇编里面调用 C 函数时, 如何为它建立栈帧以及如何给它传参数,

  在调用 C 函数时, 需要手动为它建立栈帧, 在函数结束后把栈帧销毁掉, 具体汇编代码如下:

  push ebp
  mov ebp, esp
  call cFunc
  mov esp, ebp
  pop ebp
  

  可以看到栈指针 esp 是通过 ebp 来进行备份和还原的, 之所以这么做是因为 esp 之后要被手动修改, 这导致只靠 PUSH 和 POP 指令是无法在函数结束时正确还原 esp 的.

  需要注意的是实际上 C 函数本来在编译时, GNU 就为它们建立好栈帧了, 接下来的例子中分配栈帧只是为了遵守规范,

  后面我们在 C 语言是如何与汇编对应的 解释 GNU 是如何为 C 函数建立栈帧的.

  在 x86-64 的 ABI 规范中只需要把寄存器换成它们的拓展寄存器就好了: rbp 以及 rsp.

  不过这里隐藏了一个细节: 在调用函数前, 要确保栈指针在 CALL 指令执行后能够对齐 n 字节边界(n-byte boundary, nB boundary, n-byte aligned, nB aligned),

  也就是栈指针的值满足 \(*sp\ \ rem\ \ n = 0\), 并且 n 要满足 \(n = 2^{x}, x \in \mathbb{Z}\), 换个角度就是 \(*sp\) 是 \(n\) 的倍数.

  这个 n 的规定取决于 ABI 方案的定义, x86-64 的规定是 16.

  有兴趣的话可以了解一下数据对齐的概念, 当人们说数据要对齐 16 字节边界, 就是说要求数据的内存地址是 16 的倍数.

  来一个实际例子进行比对: 调用 Glibc 的 puts 函数.

  在32位下,

  SECTION .data
  EatMsg: db "Eat at Joe's!", 0
  SECTION .bss
  SECTION .text
  extern puts
  global main
  main:
          push ebp
          mov ebp, esp
          push ebx
          push esi
          push edi
  
          push EatMsg
          call puts
          add esp, 4
  
          pop edi
          pop esi
          pop ebx
          mov esp, ebp
          pop ebp
          ret
  

  可以看到32位下调用 C 函数要用栈来传递所有参数, 把 EatMsg 作为参数压进栈再调用 puts, 最后通过手动增加栈指针的值来移动栈指针, 使其指向栈里面的上一个数据, 以此清空参数占用的内存.

  在64位下,

  SECTION .data
  EatMsg: db "Eat at Joe's!", 0
  SECTION .bss
  SECTION .text
  extern puts
  global main
  main:
          push rbp
          mov rbp, rsp
          push rbx
          push r12
          push r13
          push r14
          push r15
  
          push rdi
          mov rdi, EatMsg
          call puts
          pop rdi
  
          pop r15
          pop r14
          pop r13
          pop r12
          pop rbx
          mov rsp, rbp
          pop rbp
          ret
  

  可以注意到在调用 puts 之前一共使用了7次 PUSH 指令,也就是目前栈一共有了 \(7 \times 8\) 个字节的数据量, rsp 没有对齐到16字节边界,

  但是, CALL 指令会把返回地址压进栈,这个时候栈就有 \(8 \times 8\) 个字节的数据量,这样 rsp 就对齐,也就是这个例子我们无需手动对齐.

  如果这个例子里面多了或者少了一个 PUSH 操作,那么,我们只能再 PUSH 或者 POP 掉一个数据来进行对齐,又或者手动给 rsp 减去8(rsp 减去8意味栈增长8个字节).

  SECTION .data
  EatMsg: db "Eat at Joe's!", 0
  SECTION .bss
  SECTION .text
  extern puts
  global main
  main:
          push rax                ; extra push instruction
          push rbp
          mov rbp, rsp
          push rbx
          push r12
          push r13
          push r14
          push r15
  
          push rdi
          sub rsp, 8              ; align to 16-byte boundary
          mov rdi, EatMsg
          call puts
          add rsp, 8              ; restore %rsp to pre-aligned value
          pop rdi
  
          pop r15
          pop r14
          pop r13
          pop r12
          pop rbx
          mov rsp, rbp
          pop rbp
          pop rax
          ret
  

  其实有些系统是不强制要求对齐的, 有时候 Linux 就不强制要求, MacOS 就要求.

  这个例子其实有点过于规范了, 因为调用 puts 并没有改变 r12 到 r15 4 个寄存器, 所以它们的备份还原的指令是可以去掉的.

  再来一个比较典型的调用 printf 的例子.

  SECTION .data
  Format: db "The answer of %d + %d is %d, and don't you forget it!", 10, 0
  SECTION .bss
  SECTION .text
  extern printf
  global main
  main:
          push rbp
          mov rbp, rsp
          push rbx
  
          push rdi
          push rsi
          push rdx
          push rcx
  
          mov rdi, Format         ; first argument
          mov rsi, 3              ; second argument
          mov rdx, 2              ; third argument
          xor rcx, rcx
          add rcx, rsi
          add rcx, rdx            ; rcx is the fourth argument
          xor rax, rax            ; printf is a varargs function, there is no vector type in this example
          call printf
  
          pop rcx
          pop rdx
          pop rsi
          pop rdi
  
          pop rbx
          mov rsp, rbp
          pop rbp
          ret
  

  这个相当于 C 语言里面的这样:

  #include <stdio.h>
  int main() {
    printf("The answer of %d + %d is %d, and don't you forget it!\n", 3, 2, 5);
    return 0;
  }
  

  在汇编版本上有一个细节:

  在给 printf 传递参数前把 rax 清零了,这是因为 printf 是可变参数函数,给这种函数传递参数时需要把矢量参数的个数记录在 rax 上,

  而这个例子里面没有一个矢量参数,所以才把 rax "清零".

  如果把上面的例子改成如下,你就看不到 "清零" 这个动作了,

  #include <stdio.h>
  int main() {
    printf("The answer of %d + %d is %.2f, and don't you forget it!\n", 3, 2, 5.0);
    return 0;
  }
  

  这是因为 float 类型的 5.0 属于一个矢量参数,所以"清零"动作变成 mov rax, 1.

  在 x86-64 ABI 规定下,用于传递标量参数的通用寄存器只有6个,一旦超过这个数量,额外的参数就需要通过栈来传递了,我们把上面调用 printf 的例子改一下看看,

  SECTION .data
  Format: db "%d,%d,%d,%d,%d,%d", 10, 0
  SECTION .bss
  SECTION .text
  extern printf
  global main
  main:
          push rbp
          mov rbp, rsp
          push rbx
  
          push rdi
          push rsi
          push rdx
          push rcx
          push r8
          push r9
  
          mov rdi, Format
          mov rsi, 1
          mov rdx, 2
          mov rcx, 3
          mov r8, 4
          mov r9, 5
          sub rsp, 8              ; 10 PUSH instructions before CALL, "sub rsp, 8" so that align to 16-byte boundary after CALL
          push 7
          push 6
          call printf
          add rsp, 16             ; Stack cleanup for 2 params
          add rsp, 8
  
          pop r9
          pop r8
          pop rcx
          pop rdx
          pop rsi
          pop rdi
  
          pop rbx
          mov rsp, rbp
          pop rbp
          ret
  

  这个相当于 C 语言里面的这样:

  #include <stdio.h>
  int main() {
    printf("%d,%d,%d,%d,%d,%d,%d\n", 1, 2, 3, 4, 5, 6, 7);
    return 0;
  }
  

  printf 一共接受了8个参数,有两个参数需要用栈来传递的: 6 和 7,而且用栈传递是要注意顺序,

  在 C 语言里面可以看到数字6是第7个参数, 数字7是第8个参数, 然而在汇编里面则是先传7再传6.

  其实这不难理解, 因为栈是先进后出, 对于函数来说, 从栈里面拿的第一个参数必然是最后进去的那个.

  还有这里还进行了参数对齐, 这里需要注意绝对不能在 push 7 和 push 6 之后进行对齐的, 这会影响参数的读取.

  
  

  这些基本上就是 C 函数的调用规范了,那么可以反过来让 C 调用汇编的函数吗?

  这个章节开篇就给出了答案: 可以.

  实践起来也不难, 只需要按照调用规范定义就可以, 这里把 函数 章节里的 Acc 改成可这样的一个函数来作为例子.

  首先我们的 Makefile 是这样的,

  main: acc.o main.c
          gcc -fPIC -o main main.c acc.o
  acc.o: acc.asm
          nasm -f elf64 -g -F stabs acc.asm
  

  下面就是源代码了,其实都简单, acc.asm 是作为被调用的一方, main.c 作为调用的一方.

          ; acc.asm
  GLOBAL acc:function
  SECTION .data
  SECTION .bss
  SECTION .text
  
  acc:    xor rax, rax
  .next   cmp rdi, 0
          jle .exit
          add rax, rdi
          dec rdi
          jmp .next
  .exit:  ret
  

  /* main.c */
  #include <stdio.h>
  
  int acc(int);
  
  int main(int argc, char* argsv[]) {
    printf("The result is %d\n", acc(4));
    return 0;
  }
  

  最终运行程序 main 会打印出这样的结果: "The result is 10".

前面关于汇编程序调用 C 函数以及 C 程序调用汇编程序都只是抛砖引玉, 编译器的处理会更加复杂一点,

从栈帧建立以及销毁到内存管理都都不太一样, 如果你是想学好 C 语言, 那么这一节的学习是不可缺的.

本节的目的就是介绍如何读懂 GCC 产生的汇编码.

GCC 的汇编器 GAS 的汇编语法是 AT&T 语法, 所以这里稍微终结一下 AT&T 语法于 INTEL 语法的差异:

• AT&T 的助记符和寄存器名字全部要求小写, 而 INTEL 的是 建议 大写.
• 寄存器名字要求前面有一个百分号"%",比如 INTEL 的 EAX 在 AT&T 里面是 %eax.
• 每个支持操作数的机器指令,它们的助记符都会有一个字符后缀,用来表示操作数大小. 这些后缀分别是 b(yte), w(ord), l(ong) 以及 q(uad),比如 INTEL 的 MOV BX, AX 在 AT&T 里是 movw %ax, %bx.
• AT&T 的第一个操作数是源操作数,其次才是目的操作数,这和 INTEL 相反,前面的一点可以看出来.
• 立即操作数要求前面有一个美元符号"$",比如 INTEL 的 PUSH 64 在 AT&T 里面就是 pushl $64.
• 内存引用以及有效地址计算的语法不一样,在 INTEL 里是这样的 \(\left[base + (index \times scale) + disp\right]\),在 AT&T 则是 \(\pm disp(base, index, scale)\)
• 注释符号是 #.

一旦知道两者的差异, AT&T 语法就算上手了, 真的吗? 在"灵魂"角度上来说是的, 不过具体上两者都有自己的"私货".

接下来, 我会先介绍一些 GAS 的基础知识, 再稍微深入了解一下 C 语言一些常见的特性在汇编里面是什么样的.

通过汇编层面去了解一个程序是十分有趣的一件事情,可以了解到程序的什么地方可以优化,

但是有些另类的程序并不像 C 程序那样由机器码组成,想要给它们优化就得了解一个概念: 字节码(bytecode).

和机器码一样,字节码本质上也是二进制位序列,两者差别在于字节码并非直接由 CPU 来解析执行.

由一种叫做虚拟机(virtual machine, VM)的程序解析执行,因为它能够像 CPU 一样可以根据二进制位序列来做出对应行为.

这就是"另类的程序"能够运行的真相: 依靠虚拟机来运行.

虚拟机也有指令和助记符这些概念,类似于同架构的 CPU 所支持的指令不一样,不同的虚拟机所支持的指令也是不一样的.

如果一个虚拟机所支持的指令和 CPU 所支持的指令一样,并且该虚拟机的解释行为就和 CPU 的一样,那么这个虚拟机就是模拟了一台物理机器,可以在这个虚拟机上面运行一个操作系统.

这种模拟物理机器的的虚拟机叫做系统虚拟机(system virtual machine),常见的有 VMware, VirtualBox.

此外,一些编程语言的实现也会采用虚拟机,就像 GCC 编译器会先把 C 语言编写的源代码编译成汇编码,再汇编成机器码一样,

这些编程语言的实现会把源代码编译成字节码,然后由对应虚拟机解释执行,这种虚拟机叫做进程虚拟机(process virtual machine),

常见的编程语言 Java, Python, JavaScript 等等就有虚拟机,有些甚至支持把字节码再编译成字节码.

虚拟机的实现方法主要有两种: 基于栈进行计算的堆栈机(stack machine),以及基于寄存器进行计算的寄存器机(register machine);这也是两种计算模型.

我们学习的 x86 CPU 就是寄存器机,你可能会说,"不对,我们前面不是还有学过栈的相关指令吗,为什么 x86 CPU 会是寄存器机?"

这是因为 x86 CPU 的栈主要是用来临时储存数据的,主体计算工作依然是由寄存器来完成,所以才说 x86 CPU 是寄存器机.

而反过来,堆栈机也是一样,可能会有少量寄存器来做储存,用栈完成计算工作.

现实中, CPU 也可以采用堆栈机设计,不过很少这么做,常规 CPU 都是寄存器机设计.

如果虚拟机和 CPU 的计算模型一样,那么该虚拟机的字节码更加容易编译成该 CPU 的机器码.

为了更加直观清楚两者的差别,可以看一下在两种不同计算模型下,进行 \(2 + 3\) 的计算是什么样的一个过程,

堆栈机:

PUSH 2    // 把立即数 2 压进栈
PUSH 3    // 把立即数 3 压进栈
ADD       // 让两个栈入口的两个元素弹出,对它们进行相加: 2 + 3 = 5 ,再把结果 5 压进栈

寄存器机:

LOAD R1, 2    // 把立即数 2 加载进寄存器 1 中
LOAD R2, 3    // 把立即数 2 加载进寄存器 2 中
ADD R1, R2    // 把寄存器 R1 和 R2 上的两个数据进行相加: 2 + 3 = 5 ,再把结果 5 储存进寄存器 R1 上

常见的编程语言实现中, V8(JavaScript) 的虚拟机就是寄存器机, 官方 Python 的虚拟机就是堆栈机.

一旦你知道虚拟机是采用哪种实现, 你就可以知道如何阅读它们的字节码了, 当然你还要有它们的字节码说明.

我们将会使用最原始的材料作为根据去解析 ELF 文件, 本章节采用的是 glibc 的 elf 实现, glibc 是由 GNU 实现的一个 C 标准库, 你可以很轻松地在网络上获取到 glibc 的源代码.

如果你在使用 Linux 操作系统, 基本上只要一条命令就能获取到 glibc 的源码, 以我 Ubuntu 为例:

sudo apt-get install glibc-source

安装之后在 /usr/src 或者 /usr/local/src 里面就能找到 elf.h 这文件了(, 注意有两个 elf.h 文件的, 是 elf/elf.h 的那个).

光有源代码还不够, 我们需要一份对应的说明, 而 Linux 里面的有 man page 对 elf 进行介绍(man elf),

如果你的电脑不使用 Linux 系统, 那么请自备虚拟机, 后面的实践都是在 Linux 上完成的;

接下来会先编译一份简单的代码 C 代码得到一个 elf 文件来作为我们的大体老师, 用二进制编辑器打开它, 参考 elf.h 里的定义和 elf 的 man page 说明, 逐个字节阅读它.

首先我们的样例 C 代码:

// example.c
int func ( int, int );

int main(int argc, char **argv) {
  func(1, 2);
  return 0;
}

int func ( int a, int b ) {
  return a + b;
}

编译得到 elf 二进制文件 example (我这里是 64 位的 ELF 格式):

gcc -o example example.c

顺便编译一份 no-pie 版本:

gcc -no-pie -o example example.c

实际上每个人编译得到的 ELF 文件可能会有点差异.

由于这受到很多方面的影响, 为了保证和文章的一致性, 建议使用本文提供的文件进行练习:

下载 example

下载 example-no-pie

下载 glibc-2.39

找一个你喜欢的二进制编辑器打开它, 我个人用的是 Emacs 的 hexl-mode, 打开后界面如下:

我这里用不同的颜色把几个关键的区域给框出来了:

Area byte-data 就是 elf 文件的数据, 这里是以 16 进制呈现, 每 16 个字节为一行;

Area row-offset 上的每个值都是每一行的首个字节的偏移地址, Area col-offset 则是行内的地址偏移, 都以 16 进制表示,

(这里 Area col-offset 上面的值都是 22 这种格式, 这是由于一个字节用 16 进制表示有两位, hexl-mode 这是为了标识哪两个连续位为一个字节, 所以 22 实际上就是 0x02, 这在其它二进制编辑器上显示可能会稍有不同.)

只有把这两者结合起来才能算出字节的偏移地址, 比如第二行的那个 3e 的字节偏移地址就为 0x00000010 + 0x02 => 0x00000012;

Area ascii-encoded 就是对应 Area byte-data 的 Ascii 编码, 一个字节对应一个字符.

工具和材料已经准备得差不多了, 可以开始探索 ELF 文件格式了.

ELF 文件的内容在不同状态下的布局是不一样的, 所谓的不同状态就只有 在硬盘上储存时 以及 被加载到了内存上时 两个状态而已,

这两种状态下的 ELF 文件内容布局分别叫做 链接视图 (Linking view) 以及 执行视图 (Execution view).

二进制编辑器所展示的就是 ELF 的链接视图, 在把 ELF 文件载入到内存时,

在启动程序时, 链接器会按照 ELF 文件的信息把 sections 划分到对应的 segment 里面.

这里要强调一点, 不管在链接视图还是执行视图中, section 和 segment 两者是可以同时存在的,

它们两者与其说是不同的数据, 倒不如说是不同的计量单位.

在链接视图中, 一般是不会以 segment 作为讨论的数据对象; 同样反过来, 一般不会在执行视图中以 section 作为讨论的数据对象.

一个 segment 其实就是一个区域, 描述一个区域只需要知道它的位置和大小, 以及区域上储存了哪些 sections.

但需要注意的是, 链接视图中的 segment 划分和执行视图里面的是两回事, 我们会在后面讲程序头(program header)的时候详细讲到.

Segment 的存在是为了把程序分段加载进内存, 前面也有提到过程序在启动时并非整个加载进内存的, 每个 segment 的作用是不一样的.

本文主要是从链接视图的角度去进行解剖 ELF 文件.

整体上看去, 一个 ELF 文件的格式就是一个 ELF 头 (ELF header)后面跟着一个程序头表(program header table)或者一个节头表(section header table), 又或者是两者都有, ELF 头后面的数据就是 ELF 的文件数据.

ELF 头存在的意义是: 保证文件数据能够在链接和执行期间被正确解析. 可见 ELF 头是如此的重要.

有好多种方法可以查看到 ELF 文件的头, 最简单的就是通过 readelf 读取 ELF 的文件头:

readelf -h example

但不要忘了这一小章节的主题是逐个字节去阅读 ELF 文件, 根据文件格式标准从二进制层面上分析文件也是一项重要能力.

况且也要了解上面显示的数据有什么意义.

在 man page 里面可以看到 32 位以及 64 位 ELF 头的通用定义:

#define EI_NIDENT 16

typedef struct {
  unsigned char e_ident[EI_NIDENT];
  uint16_t      e_type;
  uint16_t      e_machine;
  uint32_t      e_version;
  ElfN_Addr     e_entry;
  ElfN_Off      e_phoff;
  ElfN_Off      e_shoff;
  uint32_t      e_flags;
  uint16_t      e_ehsize;
  uint16_t      e_phentsize;
  uint16_t      e_phnum;
  uint16_t      e_shentsize;
  uint16_t      e_shnum;
  uint16_t      e_shstrndx;
} ElfN_Ehdr;

其中 N 表示 32 或者 64. 后面统一采用 64 位作为例子.

那么怎么用这份定义呢?

C 里面的结构体的成员在内存里面是按照定义顺序储存的, 也就是说在内存里面, e_ident 一定会在 e_type 之前, e_type 一定会在 e_machine 之前, 如此类推.

成员的类型决定了成员占据多少个字节, 这也是 C 语言类型的本质: 控制数据的大小.

也就是说我们只要根据这份定义和在上面的字节一个一个的读就好.

• 成员名: e_ident; 偏移范围: 0x00 - 0x0f

  用于标识 ELF 文件标志, 好让操作系统能够识别到它是 ELF 文件.

  该成员类型是长度为 16 的 unsigned char 数组, 在 32/64 位上, 一个 unsigned char 的大小是 1 字节, 因此按照定义该成员在内存里占用 16 个字节.

  e_ident 又划分出具备不同含义的区域.

  偏移范围: 0x00 - 0x03; 字节名: EI_MAG0, EI_MAG1, EI_MAG2, EI_MAG3; 字节值: 0x7f, 0x45, 0x4c, 0x46

  是一个 magic number, 表示字符串 .ELF.

  偏移: 0x04; 字节名: EI_CLASS; 字节值: 0x02

  标识当前二进制文件的架构, 1 表示 32 位架构， 2 表示 64 位架构.

  example 是 64 位二进制文件.

  偏移: 0x05; 字节名: EI_DATA; 字节值: 0x01

  标识文件数据的字节次序(endianess), 1 是 LSB, 2 是 MSB.

  example 是 LSB 字节序.

  偏移： 0x06; 字节名: EI_VERSION; 字节值: 0x01

  标识着文件使用的 ELF 规范版本号. 1 标识当前版本, 这个值基本上可以说是固定的.

  偏移: 0x07; 字节名: EI_OSABI; 字节值: 0x00

  标识操作系统以及目标文件使用的 ABI.

  偏移: 0x08; 字节名: EI_ABIVERSION; 字节值: 0x00

  标识目标文件使用的 ABI 版本. 该字节目前未被使用, 默认为 0.

  偏移范围: 0x09 - 0x0f; 字节名: EI_PAD; 字节值: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  统一使用 0 填充的区域, 目前没有任何实际意义, 未来可能有用.

• 成员名: e_type; 偏移范围: 0x10 - 0x11; 字节值: 0x03, 0x00

  该成员的类型是 Elf64_Half, 该类型是 16 位大小, 也就是 2 个字节大小.

  用于标识目标文件类型, 1 表示可重定位文件, 2 表示可执行文件, 3 表示动态链接文件, 4 表示 core dumped 文件.

  由于 EI_DATA 是 LSB, 因此 example 的 e_type 就是 3.

  你没看错, 真的是 3, 而不是 2.

• 成员名: e_machine; 偏移范围: 0x12 - 0x13; 字节值: 0x3e, 0x00

  该成员的类型是 Elf64_Half, 该类型是 2 个字节大小.

  用于标识文件是跑在什么架构上的.

  由于 EI_DATA 是 LSB, 因此 example 的 e_machine 的值就是 0x3e, 也就是 62,

  对应宏定义 EM_X86_64, 也就是 AMD x86-64.

• 成员名: e_version; 偏移范围: 0x14 - 0x17; 字节值: 0x10, 0x00, 0x00, 0x00

  该成员的类型是 Elf64_Word, 32位大小, 也就是 4 个字节大小.

  用于标识文件版本, 目前常见的统一为 1.

  由于 EI_DATA 是 LSB, 因此 example 的 e_version 的值就是 1.

• 成员名: e_entry; 偏移范围: 0x18 - 0x1f; 字节值: 0x20, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  该成员的类型是 Elf64_Addr, 大小为 64 位, 也就是 8 字节大小.

  该成员的值是一个虚拟地址(virtual address)， 指向程序的入口.

  程序入口是指在开始运行该程序时, 操作系统需要把操控权转交到的该地址上.

  这个值实际上就是 _start 标签的内存地址, 你可以通过以下命令来验证:

  

  Figure 70: objdump -d example | grep "_start"

  _start 标签前面的地址就是 0000000000001020, 刚好对应该成员的值.

  如果是 example-no-pie 的话, _start 标签的地址就是 0000000000401020, 这是在程序映像中的绝对内存地址,

  所谓的绝对内存地址是指在每次运行程序时 _start 标签的地址都是固定这个值.

  而 example 是位置独立可执行文件(PIE, position-independent executable), 它的所有地址都是相对于程序内像首地址的偏移.

  换句话说, 假如程序在运行时被加载到 0000000000800000 这个地址上, 那么 _start 的地址就是 0000000000800000 + 0000000000001020,

  当然程序每次运行时的首地址都不是固定的, 因此在运行是 _start 的地址也不是固定的.

  在分析程序文件的二进制数据前需要先了解程序文件是 PIE 还是 no-PIE, 否则在分析地址时容易分析错误.

• 成员名: e_phoff; 偏移范围: 0x20 - 0x27; 字节值: 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  该成员为 Elf64_Off 类型, 64 位大小, 也就是 8 字节大小.

  该成员指示程序头表的偏移为多少个字节, 这里是 0x40, 也就是 64 个字节,

  也就是以 example 的 0x00 为起点, 偏移 64 个字节后的地址, 也就是 0x40, 该地址就是程序头表的首地址.

  如果不存在程序头表, 那么该值为 0.

• 成员名: e_shoff; 偏移范围: 0x28 - 0x2f; 字节值: 0xb8, 0x34, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  该成员为 Elf64_Off 类型, 占 8 字节大小.

  该成员指示节头表的偏移为多少个字节, 这里是 0x34b8 个, 也就是 13496 个字节.

  类似于 e_phoff, 从 0x00 开始偏移 134996 个字节后到达的地址 0x34b8, 该地址是节头表的首地址.

  如果不存在节头表, 那么该值为 0.

• 成员名: e_flags; 偏移范围: 0x30 - 0x33; 字节值: 0x00, 0x00, 0x00, 0x00

  成员类型为 Elf64_Word, 占 4 个字节大小.

  该成员指示处理器特定的 flags, 该成员目前未定义, 统一为 0.

• 成员名: e_ehsize; 偏移范围: 0x34 - 0x35; 字节值: 0x40, 0x00

  成员类型为 Elf64_Half, 占 2 个字节大小.

  指示 ELF 文件头的大小, example 的 ELF 头一共占用 0x40, 也就是 64 个字节.

  也就是 0x00 到 0x3f 这个范围就是 ELF 的文件头.

• 成员名: e_phentsize; 偏移范围: 0x36 - 0x37; 字节值: 0x38, 0x00

  成员类型为 Elf64_Half, 占用 2 个字节大小.

  ELF 文件的程序头表里每一项(entry, 或者说程序头)大小都是一样的, 该成员指定了程序头表每一个项的大小.

  example 程序头大小是 0x38, 也就是 56 个字节.

• 成员名: e_phnum; 偏移范围: 0x38 - 0x39; 字节值: 0x0d, 0x00

  成员类型为 Elf64_Half, 占用 2 个字节.

  指示程序头表有多少个项. 因此 e_phnum * e_phentsize 的值就是程序头表的大小.

  example 一共有 0x0d (13) 个程序头表项, 程序头表一共 \(13 \times 56 = 728\) 个字节大小.

• 成员名: e_shentsize; 偏移范围: 0x3a - 0x3b; 字节值: 0x40, 0x00

  成员类型为 Elf64_Half, 占用 2 个字节.

  ELF 文件的节头表里每一项(或者说节头)大小都是一样的, 该成员指定了节头表每一个项的大小.

  example 节头表项大小是 0x40, 也就是 64 个字节.

• 成员名: e_shnum; 偏移范围: 0x3c - 0x3d; 字节值: 0x1c, 0x00

  成员类型为 Elf64_Half, 占用 2 个字节.

  ELF 文件节头表有多少个项. 因此 e_shnum * e_shentsize 的值就是节头表的大小.

  example 一共有 0x1c, 也就是 28 个节头表项, 节头表一共 \(28 \times 64 = 1792\) 个字节大小.

• 成员名: e_shstrndx; 偏移范围: 0x3e - 0x3f; 字节值: 0x1b, 0x00

  成员类型为 Elf64_Half, 占用 2 个字节.

  如果 ELF 文件里面存在节头表, 那它就有可能存在一个项是与节头字符串表(section header string table)存在关联, 后面会详细介绍这张表.

  该成员记录了关联项在节头表中的索引, 这个成员的值是 0x1b, 也就是节头表的第 27 项(从索引 0 开始算)与节头字符串表存在关联.

程序头表是一个数组, 每个元素就是程序头, 每个程序头记录了段(segment)相关信息或者是程序运行所需的信息.

也就是说, 程序头表只对动态链接库或者可执行程序有意义.

前面也讲过, 段就是一个区域, 一个区域的信息无非就是它的位置和大小, 以及区域上有什么内容.

可以通过以下命令去查看程序头的信息:

readelf -l example

(这里的表头有进行换行, 比如 Offset 和 FileSiz 分别是两个信息.)

可以看到除了程序头信息以外, 还有一段 Section to Segment mapping 的信息,

这段信息就是告诉我们 ELF 被加载入内存时, 哪些节(section)划分为哪些段;

目标文件本身不包含 Section to Segment mapping 的信息, 根据 readelf 的源代码可以知道 readelf 是通过节和段的文件偏移(file offset)和大小(size)来得出哪个节在哪个段里面.

不过我们还是要从字节读起, 从前面的 e_phoff 成员可以知道, 从文件的第 0x40 个字节开始就是程序头了, 刚好在 ELF 头的后面.

先给出程序头的结构定义:

typedef struct
{
  Elf64_Word    p_type;             /* Segment type */
  Elf64_Word    p_flags;            /* Segment flags */
  Elf64_Off     p_offset;           /* Segment file offset */
  Elf64_Addr    p_vaddr;/* Segment virtual address */
  Elf64_Addr    p_paddr;            /* Segment physical address */
  Elf64_Xword   p_filesz;           /* Segment size in file */
  Elf64_Xword   p_memsz;            /* Segment size in memory */
  Elf64_Xword   p_align;            /* Segment alignment */
} Elf64_Phdr;

正如 ELF 头的 e_phentsize 的值 (0x38) 所示, 每个程序头的大小是 56 个字节, 这是由该结构体决定的.

限于篇幅, 这里只介绍第一个程序头, 剩下的程序头就由读者自行分析.

• 成员名: p_type; 偏移范围: 0x40 - 0x43; 字节值: 0x06, 0x00, 0x00, 0x00

  声明段的类型, 各种类型的定义如下:

  #define  PT_NULL            0               /* Program header table entry unused */
  #define  PT_LOAD            1               /* Loadable program segment */
  #define  PT_DYNAMIC         2               /* Dynamic linking information */
  #define  PT_INTERP          3               /* Program interpreter */
  #define  PT_NOTE            4               /* Auxiliary information */
  #define  PT_SHLIB           5               /* Reserved */
  #define  PT_PHDR            6               /* Entry for header table itself */
  #define  PT_TLS             7               /* Thread-local storage segment */
  #define  PT_NUM             8               /* Number of defined types */
  #define  PT_LOOS            0x60000000      /* Start of OS-specific */
  #define  PT_GNU_EH_FRAME    0x6474e550      /* GCC .eh_frame_hdr segment */
  #define  PT_GNU_STACK       0x6474e551      /* Indicates stack executability */
  #define  PT_GNU_RELRO       0x6474e552      /* Read-only after relocation */
  #define  PT_GNU_PROPERTY    0x6474e553      /* GNU property */
  #define  PT_LOSUNW          0x6ffffffa
  #define  PT_SUNWBSS         0x6ffffffa      /* Sun Specific segment */
  #define  PT_SUNWSTACK       0x6ffffffb      /* Stack segment */
  #define  PT_HISUNW          0x6fffffff
  #define  PT_HIOS            0x6fffffff      /* End of OS-specific */
  #define  PT_LOPROC          0x70000000      /* Start of processor-specific */
  #define  PT_HIPROC          0x7fffffff      /* End of processor-specific */
  

  我们例子的这个段类型是 PT_PHDR.

  我们再来翻译一下在文档上就有的几个类型吧:

  segment type	description
  PT_NULL	该类段将不会被使用, 这种段的成员全都是未定义, 这种段会被忽略.
  PT_LOAD	该类段会被加载到 p_vaddr 成员指向的地址上.
  PT_DYNAMIC	该类段储存了动态链接的信息.
  PT_INTERP	该类段存放了解释器的信息, 包括路径和大小, 这里的解析器就是链接器(linker). 比如我们的例子程序 example 的程序头有 INTERP 段, 它的链接器就是 "/lib64/ld-linux-x86-64.so.2".
  PT_NOTE	该类段存放了辅助信息的位置, 具体参考 NOTE 的数据结构定义, 是 Elf64_Nhdr(64位) 和 Elf32_Nhdr(32位).
  PT_SHLIB	该类段目前处于保留状态, 未被定义.
  PT_PHDR	该类段储存了程序头表自身在文件以及内存中的位置和大小信息.
  PT_LOPROC / PT_HIPROC	在 [ PT_LOPROC, PT_HIPROC ] 两个段之间储存了和处理器相关的数据.
  PT_GNU_STACK	该类段是 GNU 的拓展段, Linux 内核使用这种段的 p_flags 成员来控制栈的状态.

  这里需要强调一点的是, 链接视图里面只有 PT_LOAD 段会被加载到内存中, 而其它(必要的)段会被加载到 PT_LOAD 段的范围里.

  仔细观察的话你会发现所有 PT_LOAD 段结合起来的范围是覆盖了所有其它段的.

  总的来说, 在链接视图里面 ELF 文件有多少个 PT_LOAD 段, 那么在执行视图里面就有多少个段.

• 成员名: p_flags; 偏移范围: 0x44 - 0x47; 字节值: 0x04, 0x00, 0x00, 0x00

  段的掩码(bit mask), 标识段是否可写, 可读以及可执行等等.

  #define PF_X            (1 << 0)        /* Segment is executable */
  #define PF_W            (1 << 1)        /* Segment is writable */
  #define PF_R            (1 << 2)        /* Segment is readable */
  #define PF_MASKOS       0x0ff00000      /* OS-specific */
  #define PF_MASKPROC     0xf0000000      /* Processor-specific */
  

  PF_X 表示该段可以执行, PF_W 则是可写, PF-R 为可读.

  通常 text 段(text segment)是具备 PF_X 以及 PF_R; data 段则为 PF_W 以及 PF_R.

  该例子是可写段.

• 成员名: p_offset; 偏移范围: 0x48 - 0x4f; 字节值: 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  段第一个字节距离文件开始的偏移, 简称文件地址偏移.

  该段的文件地址偏移是 0x40, 也就是 64 个字节.

  当程序头的 p_type 是 PT_PHDR 时, p_offset 的值和 p_vaddr 的值是一样的.

• 成员名: p_vaddr; 偏移范围: 0x50 - 0x57; 字节值: 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  段第一个字节的虚拟地址(vritual address), 所谓虚拟地址就是在程序被加载进内存时的地址, 之所以叫虚拟内存是因为它的值并不等于内存的物理地址.

  该段的虚拟地址偏移为 0x40, 也就是 64 个字节.

• 成员名: p_paddr; 偏移范围: 0x58 - 0x5f; 字节值: 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  段第一字节的内存的物理地址. 但该成员并非总代表内存的物理地址, 并且和 p_vaddr 相同.

• 成员名: p_filesz; 偏移范围: 0x60 - 0x67; 字节值: 0xd8, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  段在文件映像(file image)No description for this link中的所占的大小, 所谓的文件映像也就是链接视图, 也就是在硬盘上的大小.

  该段的文件映像大小是 0x2d8, 也就是 728 个字节.

• 成员名: p_memsz; 偏移范围: 0x68 - 0x6f; 字节值: 0xd8, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  段在内存映像(memory image)No description for this link中所占的大小, 内存映像就是执行视图, 也就是被加载进内存用于运行时的大小.

  p_memsz 通常是大于等于 p_filesz 的, 这是因为可加载段可能会包含一些 .bss 节(section), 也就是包含一些未初始化的数据.

  该段的内存映像大小是 0x02d8, 同样也是 728 个字节.

• 成员名: p_align; 偏移范围: 0x70 - 0x77; 字节值: 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  段的数据对齐 4.

  该段的在文件映像以及内存映像中的数据对齐大小为 8 个字节, 也就是 \(p\_filesz\ \ rem\ \ 8 = p\_memsz\ \ rem\ \ 8 = 0\).

与程序头类似, 节头都是其对应节的描述, 包括节的名字, 类型, 大小等等.

从截图里面可以看到第一个节的所有位都是 0, 因此等会会用第 2 节作为讲解例子.

在 ELF 头里面 e_shoff 成员看到第一个节头的偏移是 0x34b8, 也就是说第二个节头的偏移是 \(e\_shoff + e\_shentsize = 0x34b8 + 0x40 = 0x34f8\).

先给出节头的结构体定义:

typedef struct
{
  Elf64_Word    sh_name;            /* Section name (string tbl index) */
  Elf64_Word    sh_type;            /* Section type */
  Elf64_Xword   sh_flags;           /* Section flags */
  Elf64_Addr    sh_addr;            /* Section virtual addr at execution */
  Elf64_Off     sh_offset;          /* Section file offset */
  Elf64_Xword   sh_size;            /* Section size in bytes */
  Elf64_Word    sh_link;            /* Link to another section */
  Elf64_Word    sh_info;            /* Additional section information */
  Elf64_Xword   sh_addralign;       /* Section alignment */
  Elf64_Xword   sh_entsize;         /* Entry size if section holds table */
} Elf64_Shdr;

• 成员名: sh_name; 偏移范围: 0x34f8 - 0x34fb; 字节值: 0x1b, 0x00, 0x00, 0x00

  该成员的值是"节头字符串表"(section header string table)某个数据的索引, 该表储存于名为 .shstrtab 的节上.

  .shstrtab 储存了各个节的名字字符串, 每个名字有着各自的索引.

  使用 readelf -p .shstrtab example 可以看到索引 0x1b 上的字符串为 .interp.

  也就是说该节头所描述的节的名字为 .interp.

  

  Figure 74: readelf -p .shstrtab example

• 成员名: sh_type; 偏移范围: 0x34fc - 0x34ff; 字节值: 0x01, 0x00, 0x00, 0x00

  该成员表示节的类型, 这个成员的值可能是以下中的任意一个:

  /* Legal values for sh_type (section type).  */
  
  #define SHT_NULL           0             /* Section header table entry unused */
  #define SHT_PROGBITS       1             /* Program data */
  #define SHT_SYMTAB         2             /* Symbol table */
  #define SHT_STRTAB         3             /* String table */
  #define SHT_RELA           4             /* Relocation entries with addends */
  #define SHT_HASH           5             /* Symbol hash table */
  #define SHT_DYNAMIC        6             /* Dynamic linking information */
  #define SHT_NOTE           7             /* Notes */
  #define SHT_NOBITS         8             /* Program space with no data (bss) */
  #define SHT_REL            9             /* Relocation entries, no addends */
  #define SHT_SHLIB          10            /* Reserved */
  #define SHT_DYNSYM         11            /* Dynamic linker symbol table */
  #define SHT_INIT_ARRAY     14            /* Array of constructors */
  #define SHT_FINI_ARRAY     15            /* Array of destructors */
  #define SHT_PREINIT_ARRAY  16            /* Array of pre-constructors */
  #define SHT_GROUP          17            /* Section group */
  #define SHT_SYMTAB_SHNDX   18            /* Extended section indices */
  #define SHT_NUM            19            /* Number of defined types.  */
  #define SHT_LOOS           0x60000000    /* Start OS-specific.  */
  #define SHT_GNU_ATTRIBUTES 0x6ffffff5    /* Object attributes.  */
  #define SHT_GNU_HASH       0x6ffffff6    /* GNU-style hash table.  */
  #define SHT_GNU_LIBLIST    0x6ffffff7    /* Prelink library list */
  #define SHT_CHECKSUM       0x6ffffff8    /* Checksum for DSO content.  */
  #define SHT_LOSUNW         0x6ffffffa    /* Sun-specific low bound.  */
  #define SHT_SUNW_move      0x6ffffffa
  #define SHT_SUNW_COMDAT    0x6ffffffb
  #define SHT_SUNW_syminfo   0x6ffffffc
  #define SHT_GNU_verdef     0x6ffffffd    /* Version definition section.  */
  #define SHT_GNU_verneed    0x6ffffffe    /* Version needs section.  */
  #define SHT_GNU_versym     0x6fffffff    /* Version symbol table.  */
  #define SHT_HISUNW         0x6fffffff    /* Sun-specific high bound.  */
  #define SHT_HIOS           0x6fffffff    /* End OS-specific type */
  #define SHT_LOPROC         0x70000000    /* Start of processor-specific */
  #define SHT_HIPROC         0x7fffffff    /* End of processor-specific */
  #define SHT_LOUSER         0x80000000    /* Start of application-specific */
  #define SHT_HIUSER         0x8fffffff    /* End of application-specific */
  

  这里是它们的详细说明, 建议过一遍, 不理解不要紧, 后面会慢慢懂的.

  section type	description
  SHT_NULL	该类节将不会被使用.
  SHT_PROGBITS	该类节拥有程序相关信息, 信息的格式和含义完全取决于程序.
  SHT_SYMTAB	该类节拥有一张符号表(symbol table), 一般来说这些符号用于链接编辑(link editing), 也有 可能 用于动态链接(dynamic linking). 作为一张完整的符号表, 还有可能包含各种与动态链接无关的符号. 除了 SHT_SYMTAB 类的节外, 还有 SHT_DYNSYM 类的节含有用于动态链接的符号.
  SHT_STRTAB	该类节是一个字符串表(string table), 每一项都代表着某些数据的名字. 可以有很多个这种类型的节, 每个该类型节的用途是不一样的, 比如有 SHT_STRTAB 节的项表示符号名, 有的表示节名,
  SHT_REL	该类节拥有若干个可重定位项(relocation entries). 可重定位条目有 ElfN_Rel 以及 ElfN_Rela 两种大类型(数据结构), 这里的 N 代指 32 和 64. 该类节上的条目类型是 ElfN_Rel. 一个目标文件能有多个可重定位节.
  SHT_RELA	该类节是 SHT_REL 拓展, 每一项都是 ElfN_Rel 的拓展版本 ElfN_Rela.
  SHT_HASH	该类节是一个符号哈希表(symbol hash table). 一个参与动态链接的目标文件必须有一个符号哈希表, 并且只能有一个.
  SHT_DYNAMIC	该类节拥有动态链接的信息, 这种节叫做动态节(dynamic section), 一个目标文件只能最多有一个动态节.
  SHT_NOTE	该类节拥有某些辅助信息, 参考 Elf32_Nhdr 以及 Elf64_Nhdr 数据结构.
  SHT_NOBITS	该类节在文件映像中不占任何空间, 这种节在被加载到内存时会被组合成 .bss 段.
  SHT_SHLIB	该类节只是被规范保留下来而已, 还未没有被定义.
  SHT_DYNSYM	该类节是一个极其简单的动态链接符号集合(a minimal set of dynamic linking symbols).
  SHT_LOPROC/SHT_HIPROC	在 [SHT_LOPROC, SHT_HIPROC] 中间包含了和处理器相关的数据.
  SHT_HIUSER/SHT_LOUSER	在 [SHT_LOUSER, SHT_HIUSER] 中的节类型能够被程序使用, 只要和当前以及未来定义的节类型不冲突就可以.

  想要真正理解它们的含义还是得结合实际的节描述:

  section name	description
  .bss	本节包含了那些未初始化的静态(static)和全局变量(static), 以及那些被初始化为 0 的静态和全局变量. 节类型为 SHT_NOBITS. 节的 sh_flags 为 SHF_ALLOC 和 SHF_WRITE.
  .data	本节包含已初始化的全局变量(global)和静态(static) C 变量(C variables). 局部 C 变量不会出现在这个节上. 节类型为 SHT_PROGBITS. 节的 sh_flags 为 SHF_ALLOC 和 SHF_WRITE.
  .data1	同 .data 节.
  .rodata	本节包含只读数据(read-only data), 比如 printf 的格式字符串(format strings)以及 swtich 语句的跳转表(jump table). 节类型为 SHT_PROGBITS. 节的 sh_flags 为 SHF_ALLOC.
  .rodata1	同 .rodata 节.
  .debug	本节包行一个调试符号表, 有的表项包含局部变量(local variables)的调试信息, 有的包含 typedefs 的调试信息, 有的包含全局变量(global variables), 有的包含 C 源码. 节的内容不固定. 节类型为 SHT_PROGBITS. 节的 sh_flags 为空.
  .line	本节包含 C 源码的行号(line number)和 .text 中机器指令行号之间的对应关系.节的内容不固定. 节类型为 SHT_PROGBITS. 节的 sh_flags 为空.
  .comment	本节包含一些版本控制信息, 比如用的什么编译器, 是什么版本. 节类型为 SHT_PROGBITS. 节的 sh_flags 为空.
  .ctors	本节包含已初始化的 C++ 构造函数的指针(pointers to the C++ constructor functions). 节类型为 SHT_PROGBITS. 它的 sh_flags 是 SHF_ALLOC 以及 SHF_WRITE.
  .dtors	本节包含已初始化的 C++ 析构函数(销毁函数)的指针(pointers to the C++ destructor functions). 节类型为 SHT_PROGBITS. 它的 sh_flags 是 SHF_ALLOC 以及 SHF_WRITE.
  .dynamic	本节包含动态链接信息. 节类型为 SHT_DYNAMIC. 节的 sh_flags 会包含一个 SHF_WRITE 位. SHF_WRITE 是否设置取决于处理器.
  .dynstr	本节包含动用于态链接所需的字符串, 一般都是符号表项相关的名字. 节类型为 SHT_STRTAB. 节的 sh_flags 为 SHF_ALLOC.
  .dynsym	本节包含动态链接所需的符号表. 节类型为 SHT_DYNSYM. 节的 sh_flags 为 SHF_ALLOC.
  .init	本节包含程序初始化是的指令. 在程序开始调用函数主入口前执行这些指令. 节类型为 SHT_PROGBITS. 节的 sh_flags 为 SHF_ALLOC 以及 SHF_EXECINSTR.
  .fini	本节包含程序结束时执行的指令. 在程序正常结束时执行这些指令. 节类型为 SHT_PROGBITS. 节的 sh_flags 为 SHF_ALLOC 以及 SHF_EXECINSTR.
  .interp	本节包含程序解释器(也就是链接器)的路径名字. 节的类型是 SHT_PROGBITS. 如果本节被位于一个可载入段中, 那么节的 sh_flags 的 SHF_ALLOC 会被设置为 1, 否则有 0.
  .gnu.version	本节包含版本符号表(version symbol table), 表的每一项都是 ElfN_Half 结构. 节类型是 SHT_GNU_versym. 节的 sh_flags 为 SHF_ALLOC.
  .gnu.version_d	本节包含一个版本符号定义表(version symbol definition table), 表的每一项都是 ElfN_Verdef 结构. 节类型是 SHT_GNU_verdef. 节的 sh_flags 为 SHF_ALLOC.
  .gnu.version_r	本节包含一个表, 表的每一個元素是版本符号所需的元素, 每个元素都是 ElfN_Verneed 结构. 节类型为 SHT_GNU_versym. 节的 sh_flags 为 SHF_ALLOC.
  .got	本节包含一个全局偏移表(global offset table), 每个表项是全局数据(函数或者全局变量, procedures or global variables)的偏移地址. 节类型是 SHT_PROGBITS. 节的 sh_flags 由处理器决定.
  .hash	本节包含一个符号哈希表(symbol hash table). 节类型是 SHT_HASH. 节的 sh_flags 为 SHF_ALLOC.
  .note	本节包含各种说明(notes). 节类型为 SHT_NOTE. 节的 sh_flags 为空.
  .note.ABI-tag	本节包含 ELF 镜像的运行时 ABI, 包括操作系统的名字以及它的运行时版本. 节类型为 SHT_NOTE. 节的 sh_flags 只有 SHF_ALLOC.
  .note.gnu.build-id	本节包含用于区分 ELF 镜像内容的 ID. 有着相同 ID 的不同文件应该包含同样的可执行内容. 节类型为 SHT_NOTE. 节的 sh_flags 为 SHF_ALLOC.
  .note.GNU-stack	本节是 Linux 目标文件用来储存栈的属性. 节类型为 SHT_PROGBITS. 节的 sh_flags 为 SHF_EXEINSTR, 这告诉 GNU 链接器链接的目标文件需要一个可执行栈(executable stack).
  .note.openbsd.ident	本节为 OpenBSD 的原生可执行文件通常会包含这的节, 用于标识自己是 OpenBSD 的原生可执行文件, 这样内核会在加载文件的时候绕过任何兼容性 ELF 二进制仿正测试.
  .plt	本节包含一个过程链接表(procedure linkage table). 节类型为 SHT_PROGBITS. 节的 sh_flags 为空.
  .relName	本节包含可重定位信息. 按照惯例, "NAME" 表明了该节是包含了哪个节的可重定位信息. 比如 .rel.text 就表示它含有和 .text 有关的可重定位信息. 节类型为 SHT_REL. 如果目标文件存在包含了本节的可加载段, 那么本节的 sh_flags 成员就包含 SHF_ALLOC.
  .relaName	本节包含可重定位信息. 按照惯例, "NAME" 表明了该节是包含了哪个节的可重定位信息. 比如 .rela.text 就表示它含有和 .text 有关的可重定位信息. 节类型为 SHT_RELA. 如果目标文件存在包含了本节的可加载段, 那么本节的 sh_flags 成员就包含 SHF_ALLOC.
  .shstrtab	本节包含各个节的名字. 节类型为 SHT_STRTAB. 节的 sh_flags 为空.
  .strtab	本节包含一个字符串表(string table), 这里的字符串有的是符号表(.symtab)节和 .debug 节上的项名, 有的是节头的名字. 节类型为 SHT_STRTAB. 如果目标文件有包含了符号字符串表(也就是有符号表项名的字符串表)的可加载段, 那么该字符串表对应的节的 sh_flags 为 SHF_ALLOC.
  .symtab	本节包含一个符号表(symbol table), 包含了程序里函数以及全局变量的信息 节类型为 SHT_SYMTAB. 如果目标文件有包含了符号表的可加载段, 那么该符号表对应的节的 sh_flags 就包含 SHF_ALLOC.
  .text	本节包含了程序的可执行指令. 节类型为 SHT_PROGBITS. 节的 sh_flags 为 SHF_ALLOC 和 SHF_EXECINSTR.

  该节头所描述的节的类型是 SHT_PROGBITS.

• 成员名: sh_flags; 偏移范围: 0x3500 - 0x3507; 字节值: 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  /* Legal values for sh_flags (section flags).  */
  
  #define SHF_WRITE             (1 << 0)   /* Writable */
  #define SHF_ALLOC             (1 << 1)   /* Occupies memory during execution */
  #define SHF_EXECINSTR         (1 << 2)   /* Executable */
  #define SHF_MERGE             (1 << 4)   /* Might be merged */
  #define SHF_STRINGS           (1 << 5)   /* Contains nul-terminated strings */
  #define SHF_INFO_LINK         (1 << 6)   /* `sh_info' contains SHT index */
  #define SHF_LINK_ORDER        (1 << 7)   /* Preserve order after combining */
  #define SHF_OS_NONCONFORMING  (1 << 8)   /* Non-standard OS specific handling
                                              required */
  #define SHF_GROUP             (1 << 9)   /* Section is member of a group.  */
  #define SHF_TLS               (1 << 10)  /* Section hold thread-local data.  */
  #define SHF_COMPRESSED        (1 << 11)  /* Section with compressed data. */
  #define SHF_MASKOS            0x0ff00000 /* OS-specific.  */
  #define SHF_MASKPROC          0xf0000000 /* Processor-specific */
  #define SHF_GNU_RETAIN        (1 << 21)  /* Not to be GCed by linker.  */
  #define SHF_ORDERED           (1 << 30)  /* Special ordering requirement
                                              (Solaris).  */
  #define SHF_EXCLUDE           (1U << 31) /* Section is excluded unless
                                              referenced or allocated (Solaris).*/
  

• 成员名: sh_addr; 偏移范围: 0x3508 - 0x350f; 字节值: 0x18, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  当节被加载到一个程序的内存映中时, 该成员的值就是节的首地址(虚拟地址); 否者该成员的值为 0.

  该节头描述的节的首地址是 0x318.

• 成员名: sh_offset; 偏移范围: 0x3510 - 0x3517; 字节值: 0x18, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  该成员的值是从目标文件开头到节首地址的偏移.

  由于 SHT_NOBITS 节不占文件大小, 所以这种节只是定位到文件的某个概念位置上.

  该节头所描述的节的文件偏移是 0x318.

• 成员名: sh_size; 偏移范围: 0x3518 - 0x351f; 字节值: 0x1c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

  该成员的值是节的字节大小.

  除非节的类型是 SHT_NOBITS, 否则节在文件中占据 sh_size 个字节.

  不过 SHT_NOBITS 节的该成员的值可以为非 0, 但这种节并不会正真地在文件中占有空间.

  该节头所描述的节的大小是 0x1c, 也就是 28 个字节.

• 成员名: sh_link; 偏移范围: 0x3520 - 0x3523; 字节值: 0x02, 0x00, 0x00, 0x00

  该成员的值是某种表(字符串表/符号表)在节头表中的索引(a section header index of some table),

  这个值是用来告诉链接器该节头所描述的节要和什么表进行链接, 解释方式取决于节的类型.

  section type/sh_type	sh_link
  SHT_DYNAMIC	字符串表的节头索引
  SHT_HASH	符号表的节头索引
  SHT_REL/SHT_RELA	符号表的节头索引
  SHT_SYMTAB/SHT_DYNSYM	字符串表的节头索引
  SHT_GROUP	符号表的节头索引
  SHT_SUNW_move	符号表的节头索引
  SHT_SUNW_COMDAT	0
  SHT_SUMW_syminfo	符号表的节头索引
  SHT_SUMW_verdef	字符串表的节头索引
  SHT_SUMW_verneed	字符串表的节头索引
  SHT_SUMW_versym	符号表的节头索引