库是一组目标文件的包，就是一些常用的代码编译成目标文件后打包存放。

第三章 目标文件里有什么

目标文件的格式

目标文件从结构上讲，它是已经编译后的可执行文件格式，只是还没有经过链接的过程，其中可能有些符号或者有些地址还没有被调整。

现在 PC 平台流形的可执行文件格式，主要是 Windows 下的 PE（Portable Executable）和 Linux 下的 ELF（Executable Linkable Format）,它们都是 COFF（Common file format）格式的变种。

指令和数据分开存放的好处：

• 一方面当程序被装载后，数据和指令分别被映射到两个虚存区域。由于数据区域对于进程来说是可读写的，而指令区域对于进程来说是只读的，所以这两个虚存区域的权限可以被设置成可读写和只读，这样可以防止程序的指令被有意或无意地改写。

• 另一方面是现代 CPU 有强大的缓存体系，由于缓存很重要，所以程序必须尽量提高缓存命中率。指令区和数据区分离有利于提高程序的局部性。现代 CPU 的缓存一般都被设计成数据缓存和指令缓存，所以程序的指令和数据分开存放对于 CPU 的缓存命中率提高有好处。

• 第三个原因，也是最重要的原因，就是当系统中运行着多个该进程副本时，他们的指令都是一样的，所以内存中只需要保存一份程序的指令部分。

真正了牛逼的程序员对自己的程序每一个字节都了如指掌。

objdump -h  SimpleSsection.o  # 打印elf文件各个段的信息
size SimpleSsection.o           # 查看elf文件各个段的长度
objdump -s -d SimpleSsection.o # -s将所有段内容以十六进制打印，-d将所有包含指令的段反汇编

段名称都是.前缀，表示这些表名字是系统保留的，应用程序也可以使用一些非系统保留的名字作为段名称。比如可以加入一个music段，里面存一首 mp3 音乐，运行起来后就会播放音乐，打算自定义段不能使用.作为前缀，以免与系统保留段名冲突。

Q: 如何将一个二进制文件，如图片，MP3 文件作为目标文件的一个段？ A: 可以使用 objcopy 工具，比如有一个图片 image..jpg，大小为 0x2100 字节： $ objcopy -I binary -O elf32-i388 -B i38 image.jpg image.o

正常情况下编译出来的目标文件，代码会放到.text段，但是有时候你希望变量或者某些代码能放到你指定的段中去，以实现某些特定的功能。比如为了满足某些硬件的内存和 IO 地址布局。GCC 提供了扩展机制，使得程序员可以指定变量所处的段：

__attribute__((section("FOO"))) int global = 42;
__attribute__((section("BAR"))) void foo;

ELF 文件结构

使用readelf命令查看 elf 文件详细信息。

• ELF 魔数，确认文件类型。

• 文件类型

  常量	值	含义
  ET_REL	1	可重定位文件，一般问.o文件
  ET_EXEC	2	可执行文件
  ET_DYN	3	共享目标文件，一般为.so文件

• 机器类型

  常量	值	含义
  EM_M32	1	AT&T WE 32100
  EM_SPARC	2	SPARC
  EM_M386	3	Intel x86
  EM_68K	4	Motorola 68000
  EM_88K	5	Motorola 88000
  EM_860	6	Intel 80860

段表是保存各个段的基本属性的结构。段表是除文件头外最重要的结构。编译器，链接器和装载器都是依靠段表来定位和访问各个段的属性。

链接的接口 - 符号

符号表结构

链接过程的本质就是要把多个不同的目标文件之间相互粘到一起。

目标文件 B 要用到目标文件 A 的函数foo，我们称目标文件 A定义了函数foo，目标文件 B引用了目标文件 A 的函数foo。

链接中，我们将函数和变量统称为符号，函数名或变量名就是符号名。、

每一个目标文件都会有一个相应的符号表，表里记录了目标文件中所用到的所有符号。每个符号都有一个对应值，叫符号值，对于变量和函数来说，符号值就是他们的地址。

符号类型：

• 定义在本目标文件的全局符号，可以被其他目标引用。
• 在本目标文件中应用的全局符号，却没有定义在本目标文件。
• 段名称，也就是段起始地址。
• 局部符号，一些静态变量等。
• 行号信息。

最重要的就是第一类和第二类。链接只关心全局符号的相互粘合，其他都是次要的。

可以使用 readelf objdump nm等命令查看符号信息。

特殊符号

一些特殊符号，没有在程序中定义，但是可以直接声明并引用它：

• __executable_start，程序起始地址，不是入口地址，是程序最开始的地址。
• __etext __etext etext 代码段结束地址，代码段最末尾的地址。
• _edata edata 数据段结束地址，数据段最末尾地址。
• __end end 程序结束地址。

符号修饰

符号应与对应的函数或者变量同名，但是在 C 语言发明时，已经存在了很多库和目标文件，如果再用一样的函数或变量就会冲突为了避免冲突，C 语言编译后符号名前会加上下划线_，如foo变成_foo，Fortran 语言编译后会在符号前后加上下划线_foo_。

C++具有类，继承，重载等复杂机制，为了支持这些复杂特性，人们发明了符号修饰和符号改编。

函数签名包含了一个函数的信息，包括函数名，参数类型，所在类和名称空间等信息。它用于识别不同的函数。在编译器和链接器处理符号时，使用某种名称修饰的方法，是的每个函数签名对应一个修饰后名称。

由于不同的编译器采用不同的名字修饰方式，必然导致由不同编译器编译产生的目标文件无法正常互相链接，这是导致不同编译器之间不能互操作的主要原因之一。

extern C

C++为了兼容 C，C++编译器会将在extern C 的大括号内部的代码当做 C 语言代码处理，这样就不会使用 C++的名称修饰机制。（也就不会在编译的时候加上下划线）

但是 C 语言并不支持extern C关键字，又不能为同一个库函数写两套头文件，这时候就可以用 C++的宏，__cplusplus。C++编译器会在编译 C++的程序时默认定义这个宏，我们可以用条件宏来判断当前编译单元是不是 C++代码。

#ifdef __cplusplus
extern "C" {
#endif

void *memset(void *, int , size_t);

#ifdef __cplusplus
}
#endif

弱符号与强符号

我们经常碰到符号重定义，多个目标文件中含有相同名字全局符号的定义，那么这些目标文件链接的时候就会出现符号重定义的错误。比如在两个文件中定义了相同的全局变量。

对于C/C++来说，编译器默认函数和初始化了的全局变量为强符号，未初始化的全局变量为弱符号。

也可以使用 GCC 的__attribute__((weak))来定义任何一个强符号为弱符号。

• 不允许强符号被多次定义，如果多次定义，则链接器报重复定义错误；
• 如果一个符号在某文件中是强符号，在其他文件中都是弱符号，那么选择强符号。
• 如果一个符号在所有目标文件中都是弱符号，那么选择其中占用空间最大的一个。

第四章 静态链接

空间地址分配

可执行文件中的代码段和数据段就是多个文件合并而来的，对于多个文件链接器如何将它们合并到输出文件？

按序叠加：最简单的方式，按照输入文件顺序依次合并。这会导致大量碎片，比如 x86 的硬件，段的装载地址和空间的对齐单位是页，也就是 4096 字节，那么如果一个段的长度只有 1 字节，它在内存里也要占用 4096 字节。

相似段合并：将所有相同性质的段合并在一起。

现在的链接器基本上采用第二种。使用这种方法的链接器都采用一种叫两步链接的方法。

第一步，空间与地址分配。扫描所有的输入目标文件，并且获得各个段的长度，属性和位置，并将输入目标文件中的符号表所有的符号定义和符号引用收集起来，统一放到一个全局符号表。这一步，链接器将能够获得所有输入目标文件的段长度，并且将他们合并，计算出输出文件中各个段合并后的长度和位置，并建立映射关系。

第二部，符号解析与重定位。使用上面收集到的信息，读取输入文件中段的数据，重定位信息。并且进行符号解析与重定位，调整代码中的地址。

VMA（Virtual Memory Address）虚拟地址，LMA（Load Memory Address）加载地址。正常情况这两个值是一样的。

链接之前目标文件的所有短 VMA 都是 0，因为虚拟空间还没有被分配，默认为 0，链接之后各个段就会被分配相应的虚拟地址。

Linux 下，ELF 可执行文件默认从地址0x8048000开始分配。

符号解析与重定位

objdump -d  查看代码段反汇编结果

源代码在编译成目标文件时并不知道函数的调用地址。需要通过链接时重定位。

链接器如何知道哪些指令需要被调整？这就用到了重定位表。

重定位表就是 ELF 文件的一个段，所以其实重定位表也可以叫重定位段。

objdump -r 查看重定位表

每个要被重定位的地方叫一个重定位入口（Relocation Entry）。

重定位过程也伴随着符号的解析过程，每个目标文件都可能定义一些符号，或引用到定义在其他文件的符号。重定位过程中，每个重定位的入口都是对一个符号的引用，那么当链接器需要对某个符号的引用进行重定位时，他就要确定这个符号的目标地址。这时候链接器就会取查找由所有输入目标文件的符号表组成的全局符号表，找到对应的符号进行重定位。

readelf -s 查看符号表

对于 32 位 x86 平台下的 ELF 文件的重定位入口所修正的指令寻址方式只有两种：

• 绝对近址 32 位寻址
• 相对近址 32 位寻址

x86 基本重定位类型

A = 保存在被修正位置的值 P = 被修正的位置 (相对于段开始的偏移量或者虚拟地址)，注意，该值可通过 r_offset 计算得到 S = 符号的实际地址，即由 r_info的高 24 位指定的符号的实际地址

第六章 可执行文件的装载与进程

程序运行时是有局部性原理的，所以我们可以将程序最常用的部分驻留在内存中，将不常用的数据存放在磁盘里，这就是动态载入的基本原理。

COMMON 块

Q:在目标文件中，编译器为什么不直接把未初始化的全局变量也当做未初始化的局部静态变量一样处理，为它在 BSS 段分配空间，而是将其标记为一个 COMMON 类型的变量？ A:当编译器将一个编译单元编译成目标文件时，如果该编译单元包含了弱符号（未初始化的全局变量就是典型），那么该弱符号最终所占大小未知，因为有可能其他编译单元中该符号所占空间比当前的大所以编译器此时无法为该符号在 BSS 段分配空间。但链接器在链接过程中可以确定弱符号大小，因为当链接器读取所有输入目标文件后，任何一个弱符号大小都可以确定，所以它可以在最终输出文件的 BSS 段为其分配空间。总体来看，未初始化全局变量最终还是被放在 BSS 段。

GCC 的-fno-common吧所有未初始化的全局变量不以 COMMON 块形式处理。

__attribute__扩展也可以实现，int global __attribute__((nocommon))。这样未初始化的全局变量就是强符号。

Q: 为什么静态运行库里面一个目标文件只包含一个函数？比如 libc.o 里面 printf.o 只包含 printf() 函数，strlen.o 只有 strlen 函数？ A:因为链接器在链接静态库时是以目标文件为单位的，比如我们引用了静态库中的 printf 函数，那么链接器就会把库中包含 printf 函数的那个目标文件链接进来，如果很多函数写在一个目标文件中，就将没用到的函数一起链接进了输出结果中。

链接的过程控制

第 6 章 可执行文件的装载与进程

程序运行时是有局部性原理的，所以我们可以将程序最常用的部分驻留在内存中，将不常用的数据存放在磁盘里，这就是动态载入的基本原理。

可执行文件在装载时实际上是被映射的虚拟空间，所以可执行文件又被叫做映像文件 (Image)。

Segment 和 Section 很难从中文翻译上区分，ELF 文件按 Section 存储的，从装载的角度 ELF 文件又可以按照 Segment 划分。

段地址对齐

可执行文件需要被装载，装载一般通过虚拟内存页映射机制完成，页是映射的最小单位，对于 x86 处理器来说，默认页大小为 4096 字节，所以内存空间的长度必须是 4096 的整数倍，并且这段空间在物理内存和进程虚拟地址空间的起始地址必须是 4096 的整数倍。

第 7 章 动态链接

第七章 动态链接

为什么要动态链接？

• 内存和磁盘空间：如果两个程序都用到一个静态库，链接时就会有静态库的两个副本，运行时就会占用两份内存。
• 程序的开发与发布：一个程序用到的静态库如果有更新，那么程序就需要重新链接，发布给用户。

要解决以上问题，最简单的方法就是把程序的模块相互分割开来，形成独立的文件，而不再将它们静态链接。就是不对目标文件进行链接，而等到程序运行时再链接。这就是动态链接的基本思想。

动态链接模块的装载地址是从0x00000000开始的。

共享对象的最终装载地址在编译时是不确定的。

地址无关代码

静态共享库：将程序的各个模块交给操作系统管理，操作系统在某个特定的地址划分出一些地址块，为那些已知的模块预留足够的空间。

装载时重定位：程序在编译时被装载的目标地址为0x1000，但是在装载时操作系统发现0x1000这个地址已经被别的程序使用了，从0x4000开始有一块足够大的空间可以容纳，那么该程序就可以被装载至0x4000，程序指令和数据所有引用都只需要加上0x3000偏移量即可。因为他们在程序中的相对位置是不会改变的。

地址无关代码为了解决共享对象指令中对绝对地址的重定位问题，基本想法是把指令中那些需要被修改的部分分离出来，跟数据部分放在一起，这样指令部分就可以保持不变，而数据部分可以在每个进程中拥有一个副本。

模块中四类地址引用：

模块内部调用或者跳转 不需要重定位，本身就是地址无关的。

模块内部数据访问 指令中不能包含数据的绝对地址，所以使用相对寻址的方式。

模块间数据访问 把跟地址相关的部分放到数据段里面。ELF 的做法是在数据段里面建立一个指向这些数据的指针数据，称为全局偏移表（GOT）。当代码需要引用全局变量时，可以通过 GOT 间接引用。

链接器在装载时会查找每个变量的地址，填充 GOT 每个项，当指令中需要访问变量时，程序会先找到 GOT，根据 GOT 中对应的地址，找到对应的变量。GOT 本身放在数据段，所以他可以在模块装载时被修改，并且每个进程有独立副本，相互不影响。

以访问变量 b 为例，程序首先计算出变量 b 的地址在 GOT 中的位置，即

0x10000000 + 0x454 + 0x118c + 0xfffffff8 = 0x100015d8

0xfffffff8为-8的补码表示，然后使用寄存器间接寻址方式给变量 b 赋值 2。

模块间调用跳转 类似于模块机数据访问，不同的是 GOT 中相应项保存的是目标函数的地址。

各种地址引用方式

Q : -fpic 和-fPIC 的区别？ A: 都是 GCC 产生地址无关代码的参数。-fpic产生的代码较小，-fPIC产生的代码较大。因为地址无关代码和硬件平台相关，在一些平台上-fpic会受到限制，比如全局符号的数量或者代码长度等，而后者没有这样的限制。

Q: 如果一个共享对象 lib.so 中定义了一个全局变量 G，进程 A 和进程 B 都是用了 lib.so。那么当进程 A 改变这个全局变量时，进程 B 的 G 是否受到影响？ A: 不会，应当 lib.so 被加载时，它的数据段部分在每个进程都有独立的副本。如果是同一个进程里的线程 A 和线程 B，那么他们是共享数据 G 的。

如果代码不是地址无关的，它就不能被多个进程共享，就失去了节省内存的优点。但是装载是重定位的共享对象的运行速度要比使用地址无关代码的共享对象快，因为它省去了地址无关代码中每次访问全局数据和函数是需要做一次计算当前地址以及间接地址寻址的过程。

延迟绑定 PLT

动态链接要比静态链接慢，一是因为动态链接下，对全局和静态数据的访问都要进行复杂的 GOT 定位，然后间接寻址。另外，程序开始执行时，动态链接器都要进行一次链接工作。

而在一个程序运行过程中，可能很多函数在程序执行完时都不会用到，如果一开始就把所有函数链接好实际就是一种浪费，所有 ELF 采用了一种叫做延迟绑定的做法，基本思想就是当函数第一次使用时才进行绑定（符号查找，重定位等）。

ELF 使用 PLT（Procedure Linkage Table）来实现延迟绑定。以调用bar()函数为例，之前的做法是通过 GOT 中的相应项进行跳转，而延迟绑定下，在这过程中间加了一层 PLT 间接跳转。每个外部函数在 PLT 中都有一个对应项，比如bar()在 PLT 中项的地址为bar@plt。

bar@plt:
    jmp *(bar@GOT)
    push n
    push moduleID
    jump _dl_runtime_resolve

第一条是指令通过 GOT 间接跳转的指令，如果链接器在初始化阶段已经初始化该项，并将bar()地址填入该项，那么就能正确跳转到bar()。但是为了延迟绑定，链接器初始化时并没有将bar()地址填入，而是将第二条指令push n的地址填入了bar@GOT中，这一步不需要查找符号，代价很低。

第一条指令的效果就是跳转到第二条指令，第二条指令将数字n压入堆栈，这个数字是bar这个符号引用在重定位表.rel.plt中的下标。第三条指令将模块 ID 压入堆栈，最后跳转到_dl_runtime_resolve。

_dl_runtime_resolve进行一系列工作后将bar()真正地址填入到bar@GOT。

一旦bar()这个函数被解析完，当面再次调用bar@plt时，第一条jump指令就能跳转到bar()的真正地址。bar()函数返回时根据堆栈里保存的EIP直接返回到调用者，而不会执行bar@plt中第二条指令。那段代码只会在符号未被解析时执行一次。

PLT 在 ELF 文件中以独立段存在，段名通常叫做.plt，因为它本身是一些地址无关的代码，所以可以跟代码段合并成同一个可读可执行的 Segment 被装载入内存。

动态链接相关结构

.interp 段

objdump -s a.out

Contents of section .interp:
804811 2f6c6962 2f6c696d 6c696e78 782e736f  /lib/ld-linux.so.2

里面保存的就是可执行文件所需要的动态链接器的路径，在 Linux 下，可执行文件动态链接器几乎都是/lib/ld-linux.so.2。

这是个软链接，会他会指向系统中安装的动态链接器。当系统中的 Glibc 库更新时，软链接也会指向新的动态链接器，所以.interp段不需要修改。

可以通过以下命令查看可执行文件需要的动态链接器的路径：

$ readelf -l a.out | grep interpreter
    [Requesting program interpreter: /lib/ld-linux.so.2]

.dynamic 段

动态链接 ELF 中最重要的结构，这里保存了动态链接器所需要的基本信息，如依赖哪些共享对象，动态链接符号表的位置，动态链接重定位表的位置，共享对象初始化代码的地址等。

动态符号表

Program1程序一来Lib.so，引用到了里面的foobar()函数，那么对于Program1来说，称Program1导入（Import）了foobar函数，foobar是Program1的导入函数。

而站在Lib.so角度来说，它定义了foobar函数，我们称Lib.so导出（Export）了foobar函数，foobar是Lib.so的导出函数。

为了表示动态链接这些模块之间的符号导入导出关系，ELF 专门有一个叫做动态符号表的段来保存这些信息，段名通常叫.dynsym。

.dynsym只保存与动态链接相关的符号，对于那些模块内部的符号，比如模块私有变量则不保存。

动态链接重定位表

PIC 模式的共享对象也需要重定位。

对于使用 PIC 技术的可执行文件或共享对象来说，虽然代码段不需要重定位，但是数据段还包含了绝对地址的引用，因为代码段中绝对地址相关的部分被分离出来，变成了 GOT，而 GOT 实际上是数据段的一部分。

目标文件的重定位在静态链接时完成，共享对象的重定位在装载时完成。

目标文件里包含专门用于重定位信息的重定位表，比如.rel.text表示是代码段重定位表，.rel.data表示数据段重定位表。

共享对象里类似的重定位表叫做.rel.dyn和.rel.plt。.rel.dyn实际上是对数据引用的修正，它所修正的位置位于.got以及数据段；.rel.plt实际上是对代码引用的修正，它所修正的位置位于.got.plt。

用以下命令可以查看重定位表；

printf这个重定位入口，它的类型为R_386_JUMP_SLOT，它的偏移为0x000015d8。它实际位于.got.plt中，前三项是被系统占用的，第四项开始才是真正存放导入函数地址的地方，刚好是0x000015c8 + 4 * 3 = 0x000015d4，即__gmon_start__。

当动态链接器要进行重定位时，先查找printf的地址，假设链接器在全局符号表中找到printf的地址为0x08801234，那么链接器就会将这个地址填入.got.plt中偏移为0x000015d8的位置。从而实现了地址重定位，即动态链接最关键的一步。

动态链接时进程堆栈初始化信息

动态链接的步骤和实现

动态链接分为三步：启动动态链接本身，装载所有的共享对象，重定位和初始化。

Q：动态链接器本身是动态链接还是静态链接？ A：动态链接器本身应该是静态链接的，它不能依赖于其他共享对象，动态链接器本身使用来帮助其他 ELF 文件解决共享对象依赖问题的，如果它也依赖其他共享对象，那就陷入矛盾了。

Q：动态链接器本身必须是 PIC 的吗？ A：动态链接器可以是 PIC 的也可以不是，但是往往用 PIC 会简单一些。

Q：动态链接器可以被当做可执行文件运行，那么它的装载地址是多少？ A：ld.so 的装载地址跟一般的共享对象一样，即0x00000000。这个装载地址是一个无效的装载地址，作为一个共享库，内核在装载它时会为其选择一个合适的装载地址。

显示运行时链接

第 10 章 内存

程序的内存布局

在 32 位操作系统里，有 4GB 的寻址能力，大部分操作系统会将一部分挪给内核使用，应用程序无法直接访问这段内存。这部分称为内核空间。Windows 默认将高地址的 2GB 分给内核，Linux 默认分 1GB 给内核。

剩下的称为用户空间，在用户空间里也有一些特殊的地址区间：

• 栈：维护函数调用上下文，通常在用户空间的最高地址处分配。
• 堆：用来容纳程序动态分配的内存区域，当使用 malloc 或者 new 分配内存时，得到的内存来自于堆。通常在栈下方。
• 可执行文件映像：存储可执行文件再内存里的映像，由装载器在装载时将可执行文件的内存读取活映射到这里。
• 保留区：保留区并不是一个单一的内存区域，而是对内存中受到保护而禁止访问的内存区域的总称。比如NULL。

栈与调用惯例

栈保存了一个函数调用所需要的维护信息，通常这被称为栈帧。一般包括如下几个方面：

• 函数的返回地址和参数
• 临时变量
• 保存的上下文

一个函数的调用流程：

I386 标准函数进入和退出指令序列，基本形式：

push ebp
mov ebp, esp
sub esp, x
[push reg1]
...
[push regn]

函数实际内存

[pop regn]
...
[pop reg1]
mov esp, ebp
pop ebp
ret

Hot Patch Prologue 热补丁 在 Windows 函数里，有些函数尽管使用了标准的进入指令序列，但是在这些指令之前却插入了一些特殊内容：

mov edi,edi

这条指令没有任何用，在汇编之后会成为一个占用 2 字节的机器码，纯粹为了占位符而存在，使用这条指令开头的函数整体看起来是这样的：

nop
nop
nop
nop
nop
FUNCTION:
mov edi,edi
push ebp
mov ebp, esp

其中 nop 占 1 个字节，也是占位符，FUNCTION 为一个标号，表示函数入口，本身不占空间。

设计成这样的函数在运行时可以很容易被其他函数替换掉，在上面的指令序列中调用的函数是 FUNCTION，但是我们可以做一些修改，可以在运行时刻意改成调用函数 REPLACEMENT_FUNCTION。首先在进程内存空间任意处写入 REPLACEMENT_FUNCTION 的定义：

REPLACEMENT_FUNCTION:
push ebp
mov ebp, esp
...
mov esp, ebp
pop ebp
ret

然后修改原函数的内容：

LABEL:         # 标号不占字节
jmp REPLACEMENT_FUNCTION # 占5字节，刚好五个nop
FUNCTION:      # 函数入口标号，不占字节
jmp LABEL      # 近跳指令，占2字节，跳跃到上方，即使截获失败也不影响原函数执行
push ebp
mov ebp, esp
...

将 5 个nop换成一个jmp指令，然后将占用两个字节的mov edi,edi换成另一个jmp指令。因为这个jmp指令跳转的距离非常近，因此被汇编器翻译成了一个“近跳”指令，这种指令只占用两个字节。但只能跳跃到当前地址前后 127 个字节范围的目标位置。

这里的替换机制，可以实现一种叫做钩子（HOOK）的技术，允许用户在某时刻截获特定函数的调用。

函数传递参数时压栈顺序，传递参数是寄存器传参还是栈传参等等都需要遵守一定的约定，否则函数将无法正确执行，这样的约定称为调用惯例。

一个调用惯例一般会规定如下几个方面：

• 函数参数的传递顺序和方式
  • 调用方压栈，函数自己从栈用取参数
  • 调用方压栈顺序：从左至右，还是从右至左？
• 栈的维护方式
  • 参数出栈，可以由调用方完成还是由函数自己完成？
• 名字修饰的策略
  • 为了链接的时候对调用惯例进行区分，调用惯例要对函数本身的名字进行修饰，不同调用惯例有不同的名字修饰策略
  • 没有显示指定调用惯例的函数默认是cdecl惯例

int _cdecl foo(int n, float m)

_cdel 是非标准关键字，在不同编译器中写法不同，在 gcc 中使用的是__attribute__((cdecl))

附录

文件名

整洁代码

整洁之道

• 代码是我们最终用来表达需求的那种语言，代码永存；

• 时时保持代码整洁，稍后等于永不（Later equals never）；

• 整洁代码力求集中，每个函数、每个类和每个模块都全神贯注于一件事；

• 整洁代码简单直接，从不隐藏设计者的意图；

• 整洁代码应当有单元测试和验收测试。它使用有意义的命名，代码通过其字面表达含义；

• 消除重复代码，提高代码表达力。

有意义的命名

避免误导

• “一组账号"别用accountList表示，List对程序员有特殊含义，可以用 accountGroup、bunchOfAccounts、甚至是accounts；

• 不使用区别较小的名称，ZYXControllerForEfficientHandlingOfStrings和 ZYXControllerForEfficientStorageOfStrings难以辨别；

• 不使用小写 l、大写 O 作变量名，看起来像常量 1、0。

做有意义的区分

• 不以数字系列命名(a1、a2、a3)，按照真实含义命名；

• Product/ProductInfo/ProductData 意思无区别，只统一用一个；

• 别写冗余的名字，变量名别带variable、表名别带table。

使用读得出来的名称

• genymdhms（生成日期，年、月、日、时、分、秒）肯定不如generation timestamp（生成时间戳）方便交流。

使用可搜索的名称

• 单字母名称和数字常量很难在上下文中找出。名称长短应与其作用域大小相对应，越是频繁出现的变量名称得越容易搜索 (越长)。

命名时避免使用编码

• 把类型和作用域编码进名称里增加了解码负担。意味着新人除了了解代码逻辑之外，还需要学习这种编码语言；

• 别使用匈牙利语标记法(格式：[Prefix]-BaseTag-Name 其中 BaseTag 是数据类型的缩写，Name 是变量名字)，纯属多余。例如，szCmdLine的前缀sz表示“以零结束的字符串”；

• 不必用m_前缀来表明成员变量；

• 接口和实现别在名称中编码。接口名IShapeFactory的前导"I"是废话。如果接口和实现必须选一个编码，宁可选实现，ShapeFactoryImp都比对接口名称编码来的好。

避免思维映射

• 不应当让读者在脑中把你的名称翻译为他们熟知的名称。例如，循环计数器自然有可能被命名为i或j或k，但千万别用字母l；

• 专业程序员了解，明确是王道，编写能方便他人理解的代码。

类名、方法名

• 类名应当是名词或名词短语，方法名应当是动词或动词短语。

命名不要耍宝幽默

• 言到意到，意到言到，不要在命名上展示幽默感。

每个概念用一个词

• fetch、retrieve、get约定一个一直用即可。

尽管使用计算机科学术语

• 只有程序员才会读你的代码，不需要按照问题所在邻域取名称。

别用双关语

• add方法一般语义是：根据两个值获得一个新的值。如果要把单个值加入到某个集合，用insert或append命名更好，这里用add就是双关语了。

添加有意义的语境

• 很少有名称能自我说明，需要用良好命名的类、函数、或者命名空间来放置名称，给读者提供语境，如果做不到的话，给名称添加前缀就是最后一招了。

函数

越短越好

• 短小，20 行封顶；

• if/else/while语句的代码块应该只有一行，该行应该是一个函数调用语句；

• 函数的缩进层级不应该多于一层或两层。

一个函数只做一件事

• 如果函数只是做了该函数名下同一抽象层上的步骤，则函数只做了一件事；

• 要判断函数是否不止做了一件事，就是要看是否能再拆出一个函数；

每个函数一个抽象层级

• 向下规则：让代码拥有自顶向下的阅读顺序。每个函数后面都跟着位于下一抽象层级的函数，这样一来，在查看函数列表时，就能循抽象层级向下阅读了。

switch 语句

• 把 switch 埋在较低的抽象层级，一般可以放在抽象工厂底下，用于创建多态对象。

使用描述性的名称

• 函数越短小、功能越集中，就越便于取个好名字；

• 别害怕长名称，长而具有描述性的名称，要比短而令人费解的名称好，要比描述性的长注释好；

• 别害怕花时间取名字。

函数参数

• 参数越少越好，0 参数最好，尽量避免用三个以上参数；

• 参数越多，编写组合参数的测试用例就越困难；

• 别用标识参数，向函数传入bool值是不好的，这意味着函数不止做一件事。可以将此函数拆成两个；

• 如果函数需要两个、三个或者三个以上参数，就说明其中一些参数应该封装成类了；

• 将参数的顺序编码进函数名，减轻记忆参数顺序的负担，例如 assertExpectedEqualsActual(expected, actual)。

副作用 (函数在正常工作任务之外对外部环境所施加的影响)

• 检查密码并且初始化session的方法命名为checkPasswordAndInitializeSession而非 checkPassword，即使违反单一职责原则也不要有副作用；

• 避免使用"输出参数”，如果函数必须修改某种状态，就修改所属对象的状态吧。

设置 (写) 和查询 (读) 分离

```C
if(set("username", "unclebob")) 
{ 
    ... 
}
```

含义模糊不清。应该改为:

```c
if (attributeExists("username")) 
{ 
    setAttribute("username", "unclebob");
}
```

使用异常代替返回错误码

• 返回错误码会要求调用者立刻处理错误，从而引起深层次的嵌套结构；

  if (deletePate(page) == E_OK) 
  {
      if (xxx() == E_OK) 
      {
          if (yyy() == E_OK) 
          {
              log();
          } 
          else 
          {
              log();
          }
      } 
      else 
      {
          log();
      }
  } 
  else 
  {
      log();
  }
  

• 所以需要用try catch异常机制；

  try 
  {
      deletePage();
      xxx();
      yyy();
      zzz();
  } catch (Exception e) 
  {
      log(e->getMessage());
  }
  

• try/catch代码块丑陋不堪，所以最好把try和 catch代码块的主体抽离出来，单独形成函数。

  try 
  {
      do();
  } catch (Exception e) 
  {
      handle();
  }
  

不要写重复代码

• 重复是软件中一切邪恶的根源。当算法改变时需要修改多处地方。

结构化编程

• 只要函数保持短小，偶尔出现的return、break、continue语句没有坏处，甚至还比单入单出原则更具有表达力。goto只有在大函数里才有道理，应该尽量避免使用。

• 并不需要一开始就按照这些规则写函数，没人做得到。想些什么就写什么，然后再打磨这些代码，按照这些规则组装函数。

注释

• 若编程语言足够有表现力，我们就不需要注释；

• 注释总是一种失败，因为我们无法找到不用注释就能表达自我的方法；

• 代码在演化，注释却不总是随之变动，会变得越来越不准确。

用代码来阐述

• 创建一个与注释所言同一事物的函数即可，

  // check to see if the employee is eligible for full benefits 
  if ((employee.falgs & HOURLY_FLAG) && (employee.age > 65))
  

  应替换为

  if (employee.isEligibleForFullBenefits())
  

好注释

• 法律信息，并且只要有可能就指向标准许可或者外部文档，而不是放全文；

• 提供基本信息，如解释某个抽象方法的返回值；

• 对意图的解释，反应了作者某个决定后面的意图；

• 阐释。把某些晦涩的参数或者返回值的意义翻译成可读的形式(更好的方法是让它们自身变得足够清晰，但是类似标准库的代码我们无法修改)；

  if (b.compareTo(a) == 1) //b > a
  

• 警示。// don't run unless you have some time to kill；

• TODO注释；

• 放大 一些看似不合理之物的重要性。

坏注释

• 自言自语；

• 多余的注释。把逻辑在注释里写一遍不能比代码提供更多信息，读它不比读代码简单。一目了然的成员变量别加注释，显得很多余；

• 误导性注释；

• 遵循规矩的注释。每个函数都加注释、每个变量都加注释是愚蠢的；

• 日志式注释。有了代码版本控制工具，不必在文件开头维护修改时间、修改人这类日志式的注释；

• 能用函数或者变量表示就别用注释；

  // does the module from the global list <mod> 
  
  // depend on the subsystem we are part of?
  if (smodule.getDependSubsystems().contains(subSysMod.getSubSystem())
  

  可以改为：

  ArrayList moduleDependees = smodule.getDependSubsystems();
  String ourSubSystem = subSysMod.getSubSystem();
  if (moduleDependees.contains(ourSubSystem))
  

• 位置标记。标记多了会被我们忽略掉；

  ///////////////////// Actions //////////////////////////

• 右括号注释；

  try 
  {
      while () 
      {
          if () 
          {
          ...
          } // if
          ...
      } // while
      ...
  } // try
  

  如果你想标记右括号，其实应该做的是缩短函数

• 署名 /* add by rick */ 源代码控制工具会记住你，署名注释跟不上代码的演变；

• 注释掉的代码。会导致看到这段代码其他人不敢删除，使用版本控制系统，可以大胆删除需要注释的代码；

• 信息过多。别在注释中添加有趣的历史话题或者无关的细节；

• 没解释清楚的注释。注释的作用是解释未能自行解释的代码，如果注释本身还需要解释就太遗憾了；

• 短函数的函数头注释。为短函数选个好名字比函数头注释要好；

• 非公共API函数的javadoc/phpdoc注释。

格式

垂直格式

• 短文件比长文件更易于理解。平均200行，最多不超过500行的单个文件可以构造出色的系统；

• 像报纸一样排版，由略及详，层层递进；

• 区隔: 封包声明、导入声明、每个函数之间，都用空白行分隔开，空白行下面标识着新的独立概念，表示一个思路的开始

• 靠近: 紧密相关的代码应该互相靠近，例如一个类里的属性之间别用空白行隔开；

  public class ReporterConfig 
  {
      //The class name of the reporter listener
      private String m_className;
      //The properties of the reporter listener
      private List<Property> m_properties = new ArrayList<Property>();
      public void addProperty(Property property) 
      {
          m_properties.add(property);
      }
  }
  ///////////////////////对比////////////////////////////////////
  public class ReporterConfig 
  {
      private String m_className;
      private List<Property> m_properties = new ArrayList<Property>();
      public void addProperty(Property property) 
      {
          m_properties.add(property);
      }
  }
  

• 变量声明应尽可能靠近其使用位置：循环中的控制变量应该总是在循环语句中声明；

• 成员变量应该放在类的顶部声明，不要四处放置；

• 如果某个函数调用了另外一个，就应该把它们放在一起。我们希望底层细节最后展现出来，不用沉溺于细节，所以调用者尽可能放在被调用者之上；

• 执行同一基础任务的几个函数应该放在一起。

水平格式

• 一行代码不必死守80字符的上限，偶尔到达100字符不超过120字符即可；

• 区隔与靠近: 空格强调左右两边的分割。赋值运算符两边加空格，函数名与左圆括号之间不加空格，乘法运算符在与加减法运算符组合时不用加空格(a*b - c)；

• 不必水平对齐。例如声明一堆成员变量时，各行不用每一个单词都对齐，代码自动格式化工具通常会把这类对齐消除掉；

  public class　FitNesseExpediter implements ResponseSender
  {
      private　　 Socket　　　　　　　 socket;
      private　　 InputStream　　　   input;
      private　　 OutputStream　　　  output;
      private　　 Request　　　　　　  request;
  }　　
  

• 短小的if、while、函数里最好也不要违反缩进规则，不要这样:if (xx == yy) z = 1；

• while语句为空，最好分行写分号；

  while(1)
  ;
  

团队规则

• 团队绝对不要用各种不同的风格来编写源代码，这样会增加其复杂度。

对象和数据结构

数据抽象

• 对象：暴露行为 (接口),隐藏数据 (私有变量) ；
• 数据结构：没有明显的行为 (接口),暴露数据。如DTO(Data Transfer Objects)、Entity；

数据，对象的反对称性

• 使用数据结构便于在不改动现在数据结构的前提下添加新函数；使用对象便于在不改动既有函数的前提下添加新类；

• 使用数据结构难以添加新数据结构，因为必须修改所有函数；使用对象难以添加新函数，因为必须修改所有类；

• 万物皆对象只是个传说，有时候我们也会在简单数据结构上做一些过程式的操作。

Law of Demeter

• 模块不应该了解它所操作对象的内部情形；

• class C的方法f只应该调用以下对象的方法：

  • C

  • 在方法f里创建的对象

  • 作为参数传递给方法f的对象

  • C持有的对象

• 方法不应调用 由任何函数返回的对象 的方法。下面的代码违反了 demeter 定律：

  final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
  

• 一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。

错误处理

• 错误处理很重要，但是不能凌乱到打乱代码逻辑。

使用异常而不是返回错误码

• 如果使用错误码，调用者必须在函数返回时立刻处理错误，但这很容易被我们忘记；

• 错误码通常会导致嵌套if else。

先写 try-catch 语句

• 当编写可能会抛异常的代码时，先写好try-catch再往里堆逻辑。

在 catch 里尽可能的记录

• 在catch里尽可能的记录错误信息，记录失败的操作以及失败的类型

依调用者定义异常类

• 对错误分类有很多方式。可以依其来源分类：是来自组件还是其他地方？或依其类型分类：是设备错误、网络错误还是编程错误？

别返回 null 值

• 返回null值只要一处没检查null，应用程序就会失败；

• 当想返回null值的时候，可以试试抛出异常，或者返回特例模式的对象。

别传递 null 值

• 在方法中传递null值是一种糟糕的做法，应该尽量避免；

• 在方法里用if或assert过滤null值参数，但是还是会出现运行时错误，没有良好的办法对付调动者意外传入的null值，恰当的做法就是禁止传入null值。

边界

将第三方代码干净利落地整合进自己的代码中

• 避免公共 API 返回边界接口，或者将边界接口作为参数传递给 API。将边界保留在近亲类中；

• 不要在生产代码中试验新东西，而是编写测试来理解第三方代码；

• 避免我们的代码过多地了解第三方代码中的特定信息。

• 学习性测试是一种精确试验，帮助我们增进对 API 的理解。

单元测试

TDD(Test-driven development) 三定律

• First Law: You may not write production code until you have written a failing unit test.

• Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing.

• Third Law: You may not write more production code than is sufficient to pass the currently failing test.

保持测试整洁

• 脏测试等同于没测试，测试代码越脏生产代码越难修改；

• 测试代码和生产代码一样重要；

• 整洁的测试代码最应具有的要素是：整洁性。测试代码中不要有大量重复代码的调用。

每个测试一个断言

• 每个测试函数有且仅有一个断言语句；

• 每个测试函数中只测试一个概念。

整洁的测试依赖于 FIRST 规则

• fast: 测试代码应该能够快速运行，因为我们需要频繁运行它；

• independent: 测试应该相互独立，某个测试不应该依赖上一个测试的结果，测试可以以任何顺序进行；

• repeatable: 测试应可以在任何环境中通过；

• self-validating: 测试应该有bool值输出，不应通过查看日志来确认测试结果，不应手工对比两个文本文件确认测试结果；

• timely: 及时编写测试代码。单元测试应该在生产代码之前编写，否则生产代码会变得难以测试。

类

类的组织

以下针对 JAVA 语言，其他语言类似，变量在前，方法在后，公有在前，私有在后。

• 公共静态常量

• 私有静态变量

• 私有实体变量

• 公共函数

• 私有工具函数

如果测试需要调用一个函数或变量，可以设为保护类型。

类应该短小

• 对于函数我们计算代码行数衡量大小，对于类我们使用权责来衡量；

• 类的名称应当描述其权责。类的命名是判断类长度的第一个手段，如果无法为某个类命以准确的名称，这个类就太长了。类名包含模糊的词汇，如Processor、Manager、Super，这种现象就说明有不恰当的权责聚集情况；

• 单一权责原则（Single Responsibility Principle，SRP）: 类或者模块应该有一个权责——只有一条修改的理由 (A class should have only one reason to change.)；

• 系统应该由许多短小的类而不是少量巨大的类组成；

• 类应该只有少量的实体变量，如果一个类中每个实体变量都被每个方法所使用，则说明该类具有最大的内聚性。创建最大化的内聚类不太现实，但是应该以高内聚为目标，内聚性越高说明类中的方法和变量互相依赖、互相结合形成一个逻辑整体；

• 保持内聚性就会得到许多短小的类。如果你想把一个大函数的某一小部分拆解成单独的函数，拆解出的函数使用了大函数中的 4 个变量，不必将 4 个变量作为参数传递到新函数里，仅需将这 4 个变量提升为大函数所在类的实体变量，但是这么做却因为实体变量的增多而丧失了类的内聚性，更好多做法是让这 4 个变量拆出来，拥有自己的类。将大函数拆解成小函数往往是将类拆分为小类的时机。

为了修改而组织

• 类应当对扩展开放，对修改封闭 (开放闭合原则)；

• 在理想系统中，我们通过扩展系统而非修改现有代码来添加新特性。

系统

将系统的构造与使用分开

• 软件系统应将起始过程和之后的运行逻辑分开。

分解 main

• 将全部构造过程搬迁到 main或者被称之为main的模块中，涉及系统其余部分时，假设所有对象都已经正确构造；

• 依赖注入 (DI)，控制反转 (IoC) 是分离构造与使用的强大机制。

迭代

表达力

• 作者把代码写的越清晰，其他人理解代码就越快；

• 太多时候我们深入于要解决的问题中，写出能工作的代码之后，就转移到下一个问题上，没有下足功夫调整代码让后来者易于阅读。多少尊重一下我们的手艺，花一点点时间在每个函数和类上。

尽可能少的类和方法

• 为了保持类和函数的短小，我们可能会早出太多细小的类和方法；

• 类和方法数量太多，有时是由毫无意义的教条主义导致的。

以上 4 条规则优先级依次递减。重要的是测试、消除重复、表达意图

并发编程

为什么要并发编程

• 并发总能改进性能；

• 编写并发程序无需修改设计；

• 在采用Web或EJB容器的时候，理解并发问题并不重要。

防御并发代码问题的原则与技巧

• 遵循单一职责原则。分离并发代码与非并发代码；

• 限制临界区数量、限制对共享数据的访问；

• 避免使用共享数据，使用对象的副本；

• 线程尽可能地独立，不与其他线程共享数据。