编译链接过程详解

C,C++编译，链接过程详解 1、 前言 长久以来我就一直很不清楚obj文件的内容到底是什么，有人说是汇编，有人说是机器语言。如果是机器语言的话，那编译的过程是怎样加入操作系统信息的呢？因为这个问题的不断扩展和困扰，便决定彻底研究一下，网上几乎找不到相关资料，作者参照了基本系统编程的书籍后自行整理而来，数目见底，仅供参考，欢迎讨论。 这里只研究C++的主流编译过程，与Java没有任何关系，因为使用的技术完全不一样（Java是编译和解释结合的语言）。虽然不同的编译器厂商对于程序的编译过程不尽相同，但是主要流程还是一样的。 2、 理解几个概念 首先要知道一些概念：  编译：编译器对源代码进行编译，是将以文本形式存在的源代码翻译为机器语言形式的目标文件的过程。  编译单元：对于C++来说，每一个cpp文件就是一个编译单元。从之前的编译过程的演示可以看出，各个编译单元之间是互相不可知的。  目标文件：由编译所生成的文件，以机器码的形式包含了编译单元里所有的代码和数据，以及一些其他的信息。  3、 C++编译过程 C++程序从编译到链接再到调用的整个过程是这样的： 一个C++工程中会存在cpp文件，头文件，库文件。 编译时会经历以下过程： 1． 首先经历的是预处理过程：将头文件加载进来，并且将各种#define信息代入，生成一个个独力的编译单元。 经历编译预处理过程之后会生成以cpp文件为基础的编译单元，在每个编译单元中，源码中#include的位置将被include的头文件内容替换掉，因此在以后的编程中需要严格注意include的先后顺序。因为C++语言是一种很注重申明的语言，为什么会这样，这与程序的编译过程和链接过程的算法有关。 2． 在编译单元生成之后，便是将编译单元进行编译，生成目标文件（*.obj文件） 对于主流的编译过程，通常存在两个阶段：首先是生成汇编语言，然后使用汇编器生成机器语言。机器语言顾名思义就是0101这样的二进制代码。 例如以下代码（这里写的是Intel 80x86的汇编代码，每一种不同架构的芯片的汇编语言是不同的。）: MOV AX，BX 生成机器语言的过程就是将MOV和AX和BX原封不动的用0101替换掉，如MOV代码是35， AX为01，BX为10，则翻译出来的机器码就是350110，二进制也就是001101010000000100010000。 3． 接下来的任务是链接，生成可执行文件。 链接的任务就是生成可执行文件。 其实我的一些不确认也就在这个地方。每一个程序都肯定有操作系统的一些信息，比如说程序的运行环境是DOS还是Windows程序，程序的大小等。我认为编译的整个过程中应该是在最后生成可执行文件的时候加入的。 4、 链接器的使用 许多Visual C++ 的使用者在编译源码时都碰到过以下链接错误(通常是在使用第三方库时遇到的)： LNK2005:symbol already defined LNK1169:one or more multiply defined symbols found 对于这个问题，有的朋友可能不知其然，而有的朋友可能知其然却不知其所以然，那么本文就试图为大家彻底解开关于它的种种疑惑。 大家都知道，从 C/C++ 源程序到可执行文件要经历两个阶段 : (1) 编译器将源文件编译成汇编代码，然后由汇编器 (assembler) 翻译成机器指令 ( 再加上其它相关信息 ) 后输出到一个个目标文件 (object file, VC 的编译器编译出的目标文件默认的后缀名是 .obj) 中； (2) 链接器 (linker) 将一个个的目标文件 ( 或许还会有若干程序库 ) 链接在一起生成一个完整的可执行文件。 编译器在编译源文件的时候会把源文件的全局符号 (global symbol) 分成强 (strong) 和弱 (weak) 两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。 那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号。 比如以下源文件 : extern int errorno; int buf[2] = {1,2}; int *p; int main() { return 0; } 其中 main 、buf 是强符号， p 是弱符号，而 errorno 则非强非弱，因为它只是个外部变量的使用声明（编译时不产生内存分配）。 有了强弱符号的概念，我们就可以看看链接器是如何处理与选择被多次定义过的全局符号 : 规则 1: 不允许强符号被多次定义 ( 即不同的目标文件中不能有同名的强符号 ) ； 规则 2: 如果一个符号在某个目标文件中是强符号，在其它文件中都是弱符号，那么选择强符号； 规则 3: 如果一个符号在所有目标文件中都是弱符号，那么选择其中任意一个； 由上可知多个目标文件不能重复定义同名的函数与初始化了的全局变量，否则必然导致 LNK2005 和 LNK1169 两种链接错误。 可是，有的时候我们并没有在自己的程序中发现这样的重定义现象，却也遇到了此种链接错误，这又是何解？嗯，问题稍微有点儿复杂，容我慢慢道来。 众所周知， ANSI C/C++ 定义了相当多的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 函数，而它们又分布在许多不同的目标文件中，如果直接以目标文件的形式提供给程序员使用的话，就需要他们确切地知道哪个函数存在于哪个目标文件中，并且在链接时显式地指定目标文件名才能成功地生成可执行文件，显然这是一个巨大的负担。所以 C 语言提供了一种将多个目标文件打包成一个文件的机制，这就是静态程序库 (static library) 。开发者在链接时只需指定程序库的文件名，链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块，并把 ( 且只把 ) 它们从库中拷贝出来参与构建可执行文件。几乎所有的 C/C++ 开发系统都会把标准函数打包成标准库提供给开发者使用 ( 有不这么做的吗？ ) 。 程序库为开发者带来了方便，但同时也是某些混乱的根源。我们来看看链接器是如何解析 (resolve) 对程序库的引用的。 在符号解析 (symbol resolution) 阶段，链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右把他们放入输入文件列表中，然后依次扫描它们，在此期间它要维护若干个集合 : (1) 集合 E 是将被合并到一起组成可执行文件的所有目标文件集合； (2) 集合 U 是未解析符号 (unresolved symbols ，比如已经被引用但是还未被定义的符号 ) 的集合； (3) 集合 D 是所有之前已被加入到 E 的目标文件定义的符号集合。 一开始，这三个集合都是空的。 链接器的工作过程： (1) 对命令行中的每一个输入文件 f ，链接器确定它是目标文件还是库文件，如果它是目标文件，就把 f 加入到 E ，并把 f 中未解析的符号和已定义的符号分别加入到 U 、 D 集合中，然后处理下一个输入文件。 (2) 如果 f 是一个库文件，链接器会尝试把 U 中的所有未解析符号与 f 中各目标模块定义的符号进行匹配。如果某个目标模块 m 定义了一个 U 中的未解析符号，那么就把 m 加入到 E 中，并把 m 中未解析的符号和已定义的符号分别加入到 U 、 D 集合中。不断地对 f 中的所有目标模块重复这个过程直至到达一个不动点 (fixed point) ，此时 U 和 D 不再变化。而那些未加入到 E 中的 f 里的目标模块就被简单地丢弃，链接器继续处理下一输入文件。 (3) 如果处理过程中往 D 加入一个已存在的符号，或者当扫描完所有输入文件时 U 非空，链接器报错并停止动作。否则，它把 E 中的所有目标文件合并在一起生成可执行文件。 VC 带的编译器名字叫 cl.exe ，它有这么几个与标准程序库有关的选项 : /ML 、 /MLd 、 /MT 、 /MTd 、 /MD 、 /MDd 。这些选项告诉编译器应用程序想使用什么版本的 C 标准程序库。 /ML( 缺省选项 ) 对应单线程静态版的标准程序库 (libc.lib) ； /MT 对应多线程静态版标准库 (libcmt.lib) ，此时编译器会自动定义 _MT 宏； /MD 对应多线程 DLL 版 ( 导入库 msvcrt.lib ， DLL 是 msvcrt.dll) ，编译器自动定义 _MT 和 _DLL 两个宏。 后面加 d 的选项都会让编译器自动多定义一个 _DEBUG 宏，表示要使用对应标准库的调试版，因此： /MLd 对应调试版单线程静态标准库 (libcd.lib) ， /MTd 对应调试版多线程静态标准库 (libcmtd.lib) ， /MDd 对应调试版多线程 DLL 标准库 ( 导入库 msvcrtd.lib ， DLL 是 msvcrtd.dll) 。 虽然我们的确在编译时明白无误地告诉了编译器应用程序希望使用什么版本的标准库，可是当编译器干完了活，轮到链接器开工时它又如何得知一个个目标文件到底在思念谁呢？为了传递相思，我们的编译器就干了点秘密的勾当。 在 cl 编译出的目标文件中会有一个专门的区域 ( 关心这个区域到底在文件中什么地方的朋友可以参考 COFF 和 PE 文件格式 ) 存放一些指导链接器如何工作的信息，其中有一种就叫缺省库 (default library) ，这些信息指定了一个或多个库文件名，告诉链接器在扫描的时候也把它们加入到输入文件列表中 ( 当然顺序位于在命令行中被指定的输入文件之后 ) 。 说到这里，我们先来做个小实验。写个顶顶简单的程序，然后保存为 main.c : /* main.c */ int main() { return 0; } 用下面这个命令编译 main.c( 什么？你从不用命令行来编译程序？这个 ......) : cl /c main.c /c 是告诉 cl 只编译源文件，不用链接。因为 /ML 是缺省选项，所以上述命令也相当于 : cl /c /ML main.c 。如果没什么问题的话 ( 要出了问题才是活见鬼！当然除非你的环境变量没有设置好，这时你应该去 VC 的 bin 目录下找到 vcvars32.bat 文件然后运行它。 ) ，当前目录下会出现一个 main.obj 文件，这就是我们可爱的目标文件。 随便用一个文本编辑器打开它 ( 是的，文本编辑器，大胆地去做别害怕 ) ，搜索 "defaultlib" 字符串，通常你就会看到这样的东西 : "-defaultlib:LIBC -defaultlib:OLDNAMES" 。啊哈，没错，这就是保存在目标文件中的缺省库信息。 我们的目标文件显然指定了两个缺省库，一个是单线程静态版标准库 libc.lib( 这与 /ML 选项相符 ) ，另外一个是 oldnames.lib( 它是为了兼容微软以前的 C/C++ 开发系统 ) 。 VC的链接器是 link.exe ，因为 main.obj 保存了缺省库信息，所以可以用以下命令来生成可执行文件main.exe： link main.obj libc.lib 或者 link main.obj 这两个命令是等价的。 但是如果你用以下命令： link main.obj libcd.lib 链接器会给出一个警告 : "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library" ， 因为你显式指定的标准库版本与目标文件的缺省值不一致。 通常来说，应该保证链接器合并的所有目标文件与指定的缺省标准库版本保持一致，否则编译器一定会给出上面的警告，而 LNK2005 和 LNK1169 链接错误则有时会出现有时不会。 那么这个有时到底是什么时候？呵呵，别着急，下面的一切正是为喜欢追根究底的你准备的。 建一个源文件，就叫 mylib.c ，内容如下 : /* mylib.c */ #include void foo() { printf("%s","I am from mylib!\n"); } 用 以下命令编译（ML是大小写敏感的。）： cl /c /MLd mylib.c 注意 /MLd 选项是指定 libcd.lib 为默认标准库。 lib.exe 是 VC 自带的用于将目标文件打包成程序库的命令，所以我们可以用以下命令将 mylib.obj 打包成库： lib /OUT:my.lib mylib.obj 输出的库文件名是 my.lib 。 接下来把 main.c 改成 : /* main.c */ void foo(); int main() { foo(); return 0; } 用 以下命令编译： cl /c main.c 然后用 以下命令链接： link main.obj my.lib 这个命令能够成功地生成 main.exe 而不会产生 LNK2005 和 LNK1169 链接错误，你仅仅是得到了一条警告信息 : "warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library" 。 我们根据前文所述的扫描规则来 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 一下链接器此时做了些啥。 （1）一开始 E 、 U 、 D 都是空集， 输入文件列表中存放两个文件：main.obj/my.lib （2）链接器首先在命令行中扫描到 main.obj ，把它加入 E 集合，同时把未解析的 foo 加入 U ，把 main 加入 D ，而且因为 main.obj 的默认标准库是 libc.lib ，所以它被加入到当前输入文件列表的末尾。 此时三个集合中的内容分别为（编译出的名字可能与下面列出的名字不同）： E（目标文件集合）：main.obj U（未解析符号集合，弱符号）：foo D（已定义符合集合，强符号）：main 输入文件列表中内容为：main.obj/my.lib/libc.lib （3）接着扫描到 my.lib ，因为这是个库，所以会拿当前 U 中的所有符号 ( 当然现在就一个 foo) 与 my.lib 中的所有目标模块 ( 当然也只有一个 mylib.obj) 依次匹配，看是否有模块定义了 U 中的符号。 结果 mylib.obj 确实定义了 foo ，于是它被加入到 E ， foo 从 U 转移到 D ， mylib.obj 引用的 printf 加入到 U ，同样地， mylib.obj 指定的默认标准库是 libcd.lib ，它也被加到当前输入文件列表的末尾 ( 在 libc.lib 的后面 ) 。 此时三个集合中的内容分别为（编译出的名字可能与下面列出的名字不同）： E（目标文件集合）：main.obj/mylib.obj U（未解析符号集合，弱符号）：printf D（已定义符合集合，强符号）：main/ foo 输入文件列表中内容为：main.obj/my.lib/libc.lib/ libcd.lib 不断地在 my.lib 库的各模块上进行迭代以匹配 U 中的符号，直到 U 、 D 都不再变化。很明显，现在就已经到达了这么一个不动点，所以接着扫描下一个输入文件，就是 libc.lib 。链接器发现 libc.lib 里的 printf.obj 里定义有 printf ，于是 printf 从 U 移到 D ，而 printf.obj 被加入到 E ，它定义的所有符号加入到 D ，它里头的未解析符号加入到 U 。链接器还会把每个程序都要用到的一些初始化操作所在的目标模块 ( 比如 crt0.obj 等 ) 及它们所引用的模块 ( 比如 malloc.obj 、 free.obj 等 ) 自动加入到 E 中，并更新 U 和 D 以反应这个变化。 事实上，标准库各目标模块里的未解析符号都可以在库内其它模块中找到定义，因此当链接器处理完 libc.lib 时， U 一定是空的。最后处理 libcd.lib ，因为此时 U 已经为空，所以链接器会抛弃它里面的所有目标模块从而结束扫描，然后合并 E 中的目标模块并输出可执行文件。 上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子，接下来你将目睹因为这种不严谨而导致的悲惨失败。 修改 mylib.c 成这个样子 : #include void foo() { // just a test , don't care memory leak _malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ ); } 其中 _malloc_dbg 不是 ANSI C 的标准库函数，它是 VC 标准库提供的 malloc 的调试版，与相关函数配套能帮助开发者抓各种内存错误。使用它一定要定义 _DEBUG 宏，否则预处理器会把它自动转为 malloc 。 继续用以下命令编译打包： cl /c /MLd mylib.c lib /OUT:my.lib mylib.obj 当再次用以下命令进行链接时： link main.obj my.lib 我们看到了什么？天哪，一堆的 LNK2005 加上个贵为 "fatal error" 的 LNK1169 垫底，当然还少不了那个 LNK4098 。链接器是不是疯了？不，你冤枉可怜的链接器了，我拍胸脯保证它可是一直在尽心尽责地照章办事。 输出信息： C:\>link main.obj my.lib Microsoft (R) Incremental Linker Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. LIBCD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in LIBC.lib(mall oc.obj) LIBCD.lib(dbgheap.obj) : error LNK2005: __nh_malloc already defined in LIBC.lib( malloc.obj) LIBCD.lib(dbgheap.obj) : error LNK2005: __heap_alloc already defined in LIBC.lib (malloc.obj) LIBCD.lib(dbgheap.obj) : error LNK2005: _free already defined in LIBC.lib(free.o bj) LIBCD.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in LI BC.lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in LI BC.lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_init already defined in LIBC. lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_find_block already defined in LIBC .lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_free_block already defined in LIBC .lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_block already defined in LIB C.lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined i n LIBC.lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_group already defined in LIBC.lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_resize_block already defined in LI BC.lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in LIBC.li b(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_check already defined in LIBC .lib(sbheap.obj) LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_threshold already defined in LIBC. lib(sbheap.obj) LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library main.exe : fatal error LNK1169: one or more multiply defined symbols found 连接器的工作过程如下： （1）一开始 E 、 U 、 D 为空 （2）链接器扫描 main.obj ，把它加入 E ，把 foo 加入 U ，把 main 加入 D ，把 libc.lib 加入到当前输入文件列表的末尾。 （3）接着扫描 my.lib ， foo 从 U 转移到 D ， _malloc_dbg 加入到 U ， libcd.lib 加到当前输入文件列表的尾部。 （4）然后扫描 libc.lib ，这时会发现 libc.lib 里任何一个目标模块都没有定义 _malloc_dbg( 它只在调试版的标准库中存在 ) ，所以不会有任何一个模块因为 _malloc_dbg 而加入 E ，但是每个程序都要用到的初始化模块 ( 如 crt0.obj 等 ) 及它们所引用的模块 ( 比如 malloc.obj 、 free.obj 等 ) 还是会自动加入到 E 中，同时 U 和 D 被更新以反应这个变化。 （5）当链接器处理完 libc.lib 时， U 只剩 _malloc_dbg 这一个符号。最后处理 libcd.lib ，发现 dbgheap.obj 定义了 _malloc_dbg ，于是 dbgheap.obj 加入到 E ，它里头的未解析符号加入 U ，它定义的所有其它符号也加入 D ，这时灾难便来了。 之前 malloc 等符号已经在 D 中 ( 随着 libc.lib 里的 malloc.obj 加入 E 而加入的 ) ，而 dbgheap.obj 又定义了包括 malloc 在内的许多同名符号，这引发了重定义冲突，链接器只好中断工作并 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 错误。 现在我们该知道，链接器完全没有责任，责任在我们自己的身上。是我们粗心地把缺省标准库版本不一致的目标文件 (main.obj) 与程序库 (my.lib) 链接起来，导致了大灾难。 解决办法很简单，要么用 /MLd 选项来重编译 main.c ；要么用 /ML 选项重编译 mylib.c 。 在上述例子中，我们拥有库 my.lib 的源代码 (mylib.c) ，所以可以用不同的选项重新编译这些源代码并再次打包。可如果使用的是第三方的库，它并没有提供源代码，那么我们就只有改变自己程序的编译选项来适应这些库了。 但是如何知道库中目标模块指定的默认库呢？其实 VC 提供的一个小工具便可以完成任务，这就是 dumpbin.exe 。运行下面这个命令： dumpbin /DIRECTIVES my.lib 输出信息： C:\>dumpbin /DIRECTIVES my.lib Microsoft (R) COFF Binary File Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. Dump of file my.lib File Type: LIBRARY Linker Directives ----------------- -defaultlib:LIBCD -defaultlib:OLDNAMES Summary 8 .data 27 .drectve 18 .text 然后在输出中找那些 "Linker Directives" 引导的信息，你一定会发现每一处这样的信息都会包含若干个类似 "-defaultlib:XXXX" 这样的字符串，其中 XXXX 便代表目标模块指定的缺省库名。 知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免 LNK2005 和 LNK1169 链接错误。 喜欢 IDE 的朋友，你一样可以到 "Project 属性 " -> "C/C++" -> " 代码生成 (code generation)" -> " 运行时库 (run-time library)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。 5、 参考资料： 1. 《Thinking in C++》 Bruce Eckel 机械工业出版社 2. 《高级语言程序设计》 谭浩强 清华大学出版社 3. 《计算机组成结构化方法》 Andrew S. Tanenbaum 机械工业出版社 4. 《计算机组成与设计 硬件/软件接口》 David A. Patterson John L. Hennessy 机械工业出版社 以上内容欢迎大家踊跃讨论，如有错误，欢迎指正。 描述C,C++编译和链接过程 详解link  有些人写C/C++(以下假定为C++)程序，对unresolved external link或者duplicated external simbol的错误信息不知所措（因为这样的错误信息不能定位到某一行）。或者对语言的一些部分不知道为什么要（或者不要）这样那样设计。了解本文之后， 或许会有一些答案。 首先看看我们是如何写一个程序的。如果你在使用某种IDE（Visual Studio，Elicpse，Dev C++等），你可能不会发现程序是如何组织起来的（很多人因此而反对初学者使用IDE）。因为使用IDE，你所做的事情，就是在一个项目里新建一系列 的.cpp和.h文件，编写好之后在菜单里点击“编译”，就万事大吉了。但其实以前，程序员写程序不是这样的。他们首先要打开一个编辑器，像编写文本文件 一样的写好代码，然后在命令行下敲      cc 1.cpp -o 1.o      cc 2.cpp -o 2.o      cc 3.cpp -o 3.o  这里cc代表某个C/C++编译器，后面紧跟着要编译的cpp文件，并且以-o指定要输出的文件（请原谅我没有使用任何一个流行编译器作为例子）。这样当前目录下就会出现：      1.o 2.o 3.o  最后，程序员还要键入      link 1.o 2.o 3.o -o a.out  来生成最终的可执行文件a.out。现在的IDE，其实也同样遵照着这个步骤，只不过把一切都自动化了。  让我们来分析上面的过程，看看能发现什么。  首先，对源代码进行编译，是对各个cpp文件单独进行的。对于每一次编译，如果排除在cpp文件里include别的cpp文件的情况（这是C++代码编写中极其错误的写法），那么编译器仅仅知道当前要编译的那一个cpp文件，对其他的cpp文件的存在完全不知情。  其次，每个cpp文件编译后，产生的.o文件，要被一个链接器(link)所读入，才能最终生成可执行文件。  好了，有了这些感性认识之后，让我们来看看C/C++程序是如何组织的。        下面我们具体看看编译的过程。我们跳过语法分析等，直接来到目标文件的生成。假设我们有一个1.cpp文件      int n = 1;      void f()      {       ++n;      }    它编译出来的目标文件1.o就会有一个区域（假定名称为2进制段），包含了以上数据／函数，其中有n, f，以文件偏移量的形式给出很可能就是：      偏移量    内容    长度      0x000    n    4      0x004    f     ??    注意：这仅仅是猜测，不代表目标文件的真实布局。目标文件的各个数据不一定连续，也不一定按照这个顺序，当然也不一定从0x000开始。    现在我们看看从0x004开始f函数的内容（在0x86平台下的猜测）：      0x004 inc DWORD PTR [0x000]      0x00? ret    注意n++已经被翻译为：inc DWORD PTR [0x000]，也就是把本单元0x000位置上的一个DWORD(4字节)加1。          下面如果有另一个2.cpp，如下      extern int n;      void g()      {          ++n;      }    那么它的目标文件2.o的2进制段就应该是      偏移量    内容    长度      0x000    g     ??    为什么这里没有n的空间（也就是n的定义），因为n被声明为extern，表明n的定义在别的编译单元里。别忘了编译的时候是不可能知道别的编译单元的情况的，故编译器不知道n究竟在何处，所以这个时候g的二进制代码里没有办法填写inc DWORD PTR [???]中的？？？部分。怎么办呢？这个工作就只能交给后来的链接器去处理。为了让链接器知道哪些地方的地址是没有填好的，所以目标文件还要有一个“未解决符号表”，也就是unresolved symbol table. 同样,提供n的定义的目标文件(也就是1.o)也要提供一个“导出符号表”，export symbol table, 来告诉链接器自己可以提供哪些地址。    让我们理一下思路：现在我们知道，每一个目标文件，除了拥有自己的数据和二进制代码之外，还要至少提供2个表：未解决符号表和导出符号表，分别告诉链接器 自己需要什么和能够提供什么。下面的问题是，如何在2个表之间建立对应关系。这里就有一个新的概念：符号。在C/C++中，每一个变量和函数都有自己的符号。例如变量n的符号就是“n”。函数的符号要更加复杂，它需要结合函数名及其参数和调用惯例等，得到一个唯一的字符串。f的符号可能就是"_f"（不同编译器编译出来的函数符号可能不同）。    所以，1.o的导出符号表就是      符号    地址      n    0x000      _f    0x004    而未解决符号表为空      2.o的导出符号表为      符号    地址      _g    0x000    未解决符号表为      符号    地址          n    0x001        这里0x001是从0x000开始的inc DWORD PTR [???]的二进制编码中存储???的起始地址(这里假设inc的机器码的第2－5字节为要+1的绝对地址，需要知道确切情况可查手册)。这个表告诉链接器，在本编译单元0x001的位置上有一个地址，该地址值不明，但是具有符号n。    链接的时候，链接器在2.o里发现了未解决符号n，那么在查找所有编译单元的时候，在1.o中发现了导出符号n，那么链接器就会将n的地址0x000填写到2.o的0x001的位置上。    “打住”，可能你就会跳出来指责我了。如果这样做得话，岂不是g的内容就会变成inc DWORD PTR [0x000]，按照之前的理解，这是将本单元的0x000地址的4字节加1，而不是将1.o的对应位置加1。是的，因为每个编译单元的地址都是从0开始的，所以最终拼接起来的时候地址会重复。所以链接器会在拼接的时候对各个单元的地址进行调整。这个例子中，假设2.o的0x00000000地址被定位在可执行文件的0x00001000上，而1.o的0x00000000地址被定位在可执行文件的0x00002000上，那么实际上对链接器来说，1.o 的导出符号表其实      符号    地址      n    0x000 + 0x2000      _f    0x004 + 0x2000    而未解决符号表为空     2.o的导出符号表为      符号    地址      _g    0x000 + 0x1000    未解决符号表为      符号    地址                  n    0x001 + 0x1000  所以最终g的代码会变为inc DWORD PTR [0x000 + 0x2000]。    最后还有一个漏洞，既然最后n的地址变为0x2000了，那么以前f的代码inc DWORD PTR [0x000]就是错误的了。所以目标文件为此还要提供一个表，叫做地址重定向表address redirect table。    对于1.o来说，它的重定向表为      地址      0x005    这个表不需要符号，当链接器处理这个表的时候，发现地址为0x005的位置上有一个地址需要重定向，那么直接在以0x005开始的4个字节上加上0x2000就可以了。    让我们总结一下：编译器把一个cpp编译为目标文件的时候，除了要在目标文件里写入cpp里包含的数据和代码，还要至少提供3个表：未解决符号表，导出符号表和地址重定向表。    未解决符号表提供了所有在该编译单元里引用但是定义并不在本编译单元里的符号及其出现的地址。    导出符号表提供了本编译单元具有定义，并且愿意提供给其他编译单元使用的符号及其地址。    地址重定向表提供了本编译单元所有对自身地址的引用的 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 。    链接器进行链接的时候，首先决定各个目标文件在最终可执行文件里的位置。然后访问所有目标文件的地址重定向表，对其中记录的地址进行重定向（即加上该编译单元实际在可执行文件里的起始地址）。然后遍历所有目标文件的未解决符号表，并且在所有的导出符号表里查找匹配的符号，并在未解决符号表中所记录的位置上 填写实际的地址（也要加上拥有该符号定义的编译单元实际在可执行文件里的起始地址）。最后把所有的目标文件的内容写在各自的位置上，再作一些别的工作，一个可执行文件就出炉了。    最终link 1.o 2.o .... 所生成的可执行文件大概是  0x00000000  ????（别的一些信息）  ....  0x00001000  inc DWORD PTR [0x00002000] //这里是2.o的开始，也就是g的定义  0x00001005  ret //假设inc为5个字节，这里是g的结尾  ....  0x00002000  0x00000001 //这里是1.o的开始，也是n的定义（初始化为1）  0x00002004  inc DWORD PTR [0x00002000] //这里是f的开始  0x00002009  ret //假设inc为5个字节，这里是f的结尾  ...  ...  实际链接的时候更为复杂，因为实际的目标文件里把数据／代码分为好几个区，重定向等要按区进行，但原理是一样的。  现在我们可以来看看几个经典的链接错误了：      unresolved external link..    这个很显然，是链接器发现一个未解决符号，但是在导出符号表里没有找到对应的项。    解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 当然就是在某个编译单元里提供这个符号的定义就行了。（注意，这个符号可以是一个变量，也可以是一个函数），也可以看看是不是有什么该链接的文件没有链接      duplicated external simbols...    这个则是导出符号表里出现了重复项，因此链接器无法确定应该使用哪一个。这可能是使用了重复的名称，也可能有别的原因。    我们再来看看C/C++语言里针对这一些而提供的特性：    extern:这是告诉编译器，这个符号在别的编译单元里定义，也就是要把这个符号放到未解决符号表里去。（外部链接）          static:如果该关键字位于全局函数或者变量的声明的前面，表明该编译单元不导出这个函数／变量的符号。因此无法在别的编译单元里使用。（内部链接）。如果是static局部变量，则该变量的存储方式和全局变量一样，但是仍然不导出符号。          默认链接属性：对于函数和变量，默认外部链接，对于const变量，默认内部链接。（可以通过添加extern和static改变链接属性）    外部链接的利弊：外部链接的符号，可以在整个程序范围内使用（因为导出了符号）。但是同时要求其他的编译单元不能导出相同的符号（不然就是duplicated external simbols)    内部链接的利弊：内部链接的符号，不能在别的编译单元内使用。但是不同的编译单元可以拥有同样名称的内部链接符号。    为什么头文件里一般只可以有声明不能有定义：头文件可以被多个编译单元包含，如果头文件里有定义，那么每个包含这个头文件的编译单元就都会对同一个符号进行定义，如果该符号为外部链接，则会导致duplicated external simbols。因此如果头文件里要定义，必须保证定义的符号只能具有内部链接。    为什么常量默认为内部链接，而变量不是：    这就是为了能够在头文件里如const int n = 0这样的定义常量。由于常量是只读的，因此即使每个编译单元都拥有一份定义也没有关系。如果一个定义于头文件里的变量拥有内部链接，那么如果出现多个编译单元都定义该变量，则其中一个编译单元对该变量进行修改，不会影响其他单元的同一变量，会产生意想不到的后果。    为什么函数默认是外部链接：    虽然函数是只读的，但是和变量不同，函数在代码编写的时候非常容易变化，如果函数默认具有内部链接，则人们会倾向于把函数定义在头文件里，那么一旦函数被修改，所有包含了该头文件的编译单元都要被重新编译。另外，函数里定义的静态局部变量也将被定义在头文件里。    为什么类的静态变量不可以就地初始化：所谓就地初始化就是类似于这样的情况：          class A          {              static char msg[] = "aha";          };  不允许这样做得原因是，由于class的声明通常是在头文件里，如果允许这样做，其实就相当于在头文件里定义了一个非const变量。    在C++里，头文件定义一个const对象会怎么样：    一般不会怎么样，这个和C里的在头文件里定义const int一样，每一个包含了这个头文件的编译单元都会定义这个对象。但由于该对象是const的，所以没什么影响。但是：有2种情况可能破坏这个局面：    1。如果涉及到对这个const对象取地址并且依赖于这个地址的唯一性，那么在不同的编译单元里，取到的地址可以不同。（但一般很少这么做）    2。如果这个对象具有mutable的变量，某个编译单元对其进行修改，则同样不会影响到别的编译单元。    为什么类的静态常量也不可以就地初始化：    因为这相当于在头文件里定义了const对象。作为例外，int/char等可以进行就地初始化，是因为这些变量可以直接被优化为立即数，就和宏一样。    内联函数：    C++里的内联函数由于类似于一个宏，因此不存在链接属性问题。    为什么公共使用的内联函数要定义于头文件里：    因为编译时编译单元之间互相不知道，如果内联函数被定义于.cpp文件中，编译其他使用该函数的编译单元的时候没有办法找到函数的定义，因此无法对函数进行展开。所以说如果内联函数定义于.cpp文件里，那么就只有这个cpp文件可以是用这个函数。    头文件里内联函数被拒绝会怎样：    如果定义于头文件里的内联函数被拒绝，那么编译器会自动在每个包含了该头文件的编译单元里定义这个函数并且不导出符号。    如果被拒绝的内联函数里定义了静态局部变量，这个变量会被定义于何处：    早期的编译器会在每个编译单元里定义一个，并因此产生错误的结果，较新的编译器会解决这个问题，手段未知。    为什么export关键字没人实现：    export要求编译器跨编译单元查找函数定义，使得编译器实现非常困难。 ============================================================================== 第3章 目标文件里有什么 3.1  目标文件的格式 3.2  目标文件是什么样的 3.3  挖掘SimpleSection.o 3.4  ELF文件结构描述 3.5  链接的接口--符号 3.6  调试信息 3.7  本章小结 编译器编译源代码后生成的文件叫做目标文件，那么目标文件里面到底存放的是什么呢？或者我们的源代码在经过编译以后是怎么存储的？我们将在这一节剥开目标文件的层层外壳，去探索它最本质的内容。 目标文件从结构上讲，它是已经编译后的可执行文件格式，只是还没有经过链接的过程，其中可能有些符号或有些地址还没有被调整。其实它本身就是按照可执行文件格式存储的，只是跟真正的可执行文件在结构上稍有不同。 可执行文件格式涵盖了程序的编译、链接、装载和执行的各个方面。了解它的结构并深入剖析它对于认识系统、了解背后的机理大有好处。 3.1  目标文件的格式 现在PC平台流行的可执行文件格式（Executable）主要是Windows下的PE（Portable Executable）和Linux的ELF（Executable Linkable Format），它们都是COFF（Common file format）格式的变种。目标文件就是源代码编译后但未进行链接的那些中间文件（Windows的.obj和Linux下的.o），它跟可执行文件的内容与结构很相似，所以一般跟可执行文件格式一起采用一种格式存储。从广义上看，目标文件与可执行文件的格式其实几乎是一样的，所以我们可以广义地将目标文件与可执行文件看成是一种类型的文件，在Windows下，我们可以统称它们为PE-COFF文件格式。在Linux下，我们可以将它们统称为ELF文件。其他不太常见的可执行文件格式还有Intel/Microsoft的OMF（Object Module Format）、Unix a.out格式和MS-DOS .COM格式等。 不光是可执行文件（Windows的.exe和Linux下的ELF可执行文件）按照可执行文件格式存储。动态链接库（DLL，Dynamic Linking Library）（Windows的.dll和Linux的.so）及静态链接库（Static Linking Library）（Windows的.lib和Linux的.a）文件都按照可执行文件格式存储。它们在Windows下都按照PE-COFF格式存储，Linux下按照ELF格式存储。静态链接库稍有不同，它是把很多目标文件捆绑在一起形成一个文件，再加上一些索引，你可以简单地把它理解为一个包含有很多目标文件的文件包。ELF文件标准里面把系统中采用ELF格式的文件归为如表3-1所列举的4类。 表3-1 ELF文件类型 说明 实例 可重定位文件 （Relocatable File） 这类文件包含了代码和数据，可以被用来链接成可执行文件或共享目标文件，静态链接库也可以归为这一类 Linux的.o Windows的.obj 续表 ELF文件类型 说明 实例 可执行文件 （Executable File） 这类文件包含了可以直接执行的程序，它的代表就是ELF可执行文件，它们一般都没有扩展名 比如/bin/bash文件 Windows的.exe 共享目标文件 （Shared Object File） 这种文件包含了代码和数据，可以在以下两种情况下使用。一种是链接器可以使用这种文件跟其他的可重定位文件和共享目标文件链接，产生新的目标文件。第二种是动态链接器可以将几个这种共享目标文件与可执行文件结合，作为进程映像的一部分来运行 Linux的.so，如/lib/ glibc-2.5.so Windows的DLL 核心转储文件 （Core Dump File） 当进程意外终止时，系统可以将该进程的地址空间的内容及终止时的一些其他信息转储到核心转储文件 Linux下的core dump 我们可以在Linux下使用file命令来查看相应的文件格式，上面几种文件在file命令下会显示出相应的类型： $ file foobar.o foobar.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped $ file /bin/bash /bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped $ file /lib/ld-2.6.1.so /lib/libc-2.6.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, stripped 目标文件与可执行文件格式的小历史 目标文件与可执行文件格式跟操作系统和编译器密切相关，所以不同的系统平台下会有不同的格式，但这些格式又大同小异，目标文件格式与可执行文件格式的历史几乎是操作系统的发展史。 COFF是由Unix System V Release 3首先提出并且使用的格式规范，后来微软公司基于COFF格式，制定了PE格式标准，并将其用于当时的Windows NT系统。System V Release 4在COFF的基础上引入了ELF格式，目前流行的Linux系统也以ELF作为基本可执行文件格式。这也就是为什么目前PE和ELF如此相似的主要原因，因为它们都是源于同一种可执行文件格式COFF。 Unix最早的可执行文件格式为a.out格式，它的设计非常地简单，以至于后来共享库这个概念出现的时候，a.out格式就变得捉襟见肘了。于是人们设计了COFF格式来解决这些问题，这个设计非常通用，以至于COFF的继承者到目前还在被广泛地使用。 COFF的主要贡献是在目标文件里面引入了"段