GitHub : Jerry4me
前言
我们中有许多程序员打码几年还没有搞清楚一个程序从源代码 -> 可执行程序 -> 执行 -> 死亡, 经历了什么变化. 他们只知道, 编译, 链接, 运行…由于强大的IDE已经帮我们把这些过程屏蔽掉了, 我们不知道底层他们干了什么. 但是我们只有明白这些运行机制和机理, 才能解决一些莫名其妙的错误, 提升性能瓶颈.
笔者在看了>这本书后决定把这些过程用比较简单易懂的文字叙述出来, 如有不对的地方还请各位指出, 谢谢~
目录
预编译
编译
汇编
目标文件
链接
可执行文件
装载
动态链接(需要的话)
运行
死亡
小知识
编译
编译又分为 预处理(Preprocessing), 编译(Compilation)和汇编(Assembly).
预编译
预编译过程主要处理源代码文件那些#开头的预编译指令
|
1 2 3 4 5 6 7 8 |
1. 删除所有#define, 展开所有宏定义 2. 处理所有预编译指令, 如#if, #ifdef, #elif, #else, #endif 3. 递归处理#include 4. 删除所有注释, // 和 /**/ 5. 添加行号和文件名标识 6. 保留所有#pragma编译器指令 因此如果我们无法判断宏定义是否正确, 头文件包含是否正确时 -> 查看预编译后的文件来确定问题 |
编译
编译过程可分为6部 : 扫描, 语法分析, 语义分析, 源代码优化, 代码生成和目标代码优化.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
1. 扫描 : 扫描器运用一种类似于有限状态机的算法把源代码分割成一些列的记号(Token) 2. 语法分析 : 语法分析器采用上下文无关语法(Context-free Grammar)将Token进行语法分析, 生成语法树(Syntax Tree).该语法树就是以表达式为节点的树 3. 语义分析 : 语法分析只是对表达式的语法进行层面的分析, 它并不知道该语句是否真正有意义. 在这里, 语义分析器能够进行静态语义分析, 分析过后整个语法树的表达式都被标识了类型 静态语义 : 在编译器可以确定的语义, 通常包括声明和类型的匹配, 转换. 动态语义 : 在运行时才能确定的语义, 比如0作为除数则在这里报错 4. 源代码优化 : 源码级优化器(Source Code Optimizer)在源代码级别进行优化, 把一些类似于(2+6)这些在编译器就能确定的表达式优化成值, 从而把整个语法树转换成中间代码(Intermediate Code) 中间代码使得编译器可以被分为前端和后端, 前端负责产生机器无关的中间代码, 后端将中间代码转换成目标机器代码 5. 代码生成与优化 : 代码生成器(Code Generator)将中间代码转换成目标机器代码(该过程十分依赖于目标机器), 最后目标代码优化器(Target Code Optimizer)将上述的代码进行优化, 例如选择合适的寻址方式, 使用位移来代替乘法运算, 删除多余的指令等. |
汇编
汇编器将汇编代码转换成机器可以执行的指令, 输出目标文件. 该过程比较简单, 就是翻译代码.
经过上述多个步骤, 源代码终于被编译成了目标文件. 这个目标文件肚子里又卖的是什么药呢? 我们接着看~
目标文件
由于不同的操作系统下, 目标文件, 可执行文件等都有些出入. 本文是用Linux系统下的ELF文件作为例子
编译之后生成的目标文件内容肯定少不了机器指令代码, 数据等. 不过除了这些之外, 目标文件还包括了链接时所需的一些信息, 而目标文件将这些信息按照不同的属性, 以段(Section)来存储.
|
1 2 |
程序源代码编译后的机器指令 -> 代码段(Code Section), ".code"或".text" 全局变量和局部静态变量数据 -> 数据段(Data Section), ".data"或".bss" |
Question :
为什么要把数据和指令分开呢? 经典的冯诺依曼体系不是不分指令还是数据的吗?Answer :
1 : 当程序被装载后, 数据和指令被映射到两个虚存区域. 数据区域对于进程而言, 是可读写的, 而指令区域则只可读. 这样方便分别设置他们的权限, 防止程序指令被恶意修改
2 : 把指令和数据分开有利于提高程序的局部性, 对于提高CPU缓存命中率有帮助
3 : 最重要的原因, 当系统中运行着多个该程序的副本时, 他们的指令都是一样的, 所以进程之间能共享指令和其他只读数据, 而数据区域则为进程私有. 如果系统中运行了数百个进程, 可以想象共享为我们节省了多少空间
这里插一句 : 其实不是可执行文件才才按照执行文件的格式存储. 什么意思呢? 除了可执行文件之外, 目标对象, 动态链接库, 静态链接库也按照可执行文件的格式存储. 某种程度上他们也是可执行文件. 所以我们可以把他们视为同一类文件
目标文件有什么
ELF文件头(ELF Header)
包含了整个文件的基本属性
段表(Section Header Table)
描述了ELF文件包含的所有段的信息
重定位表
链接器在处理目标文件时, 要对目标文件中某些符号进行重定位, 即代码段和数据段那些对绝对地址引用的符号. 这些重定位信息就记录在重定位表中.
符号表
在链接中, 我们将函数和变量统称为符号(Symbol), 函数名和变量名称为符号名(Symbol Name). 符号表记录着该目标文件所用到的所有符号, 每个符号都有一个对应的值, 符号值(Symbol Value), 对于函数和变量来说, 符号值就是他们的地址.
强符号与弱符号, 强引用与弱引用
如果在目标文件A和目标文件B都定义了一个全局变量global, 并将他们都初始化. 那么链接的时候就会报multiple definition of 'global'的错误. 这种符号就是强符号. 默认所有符号都是强符号, 可以使用GCC的__attribute__ ((weak))定义一个弱符号.
强符号与弱符号的规则 :
|
1 2 3 |
1. 不允许多次定义强符号 2. 如果一个符号在某个目标文件中是强符号, 在其他目标文件中是弱符号, 那么链接时选择强符号 3. 如果一个符号在全部目标文件中都是弱符号, 那么选择占用空间最大的一个. |
符号引用被最终链接的时候必须要被正确决议, 如果没有找到该符号的定义, 就会报符号未定义错误undefined symbol of xxx, 这种称为强引用(Strong Reference). 而弱引用(Weak Reference)则被处理的时候如果未定义, 不报错, 链接器会默认其为0或者是一个特殊值. 默认都是强引用, 可以使用GCC的__attribute__ ((weakref))定义一个弱引用.
弱符号和弱引用的作用 :
|
1 2 3 4 |
对于库来说十分有用, 库中定义的弱符号可以被用户定义的强符号覆盖, 程序则可以使用自定义的库函数 或者程序可以对某些扩展功能模块的引用定义为弱引用, 当我们将扩展模块与程序链接在一起时, 功能模块可以正常使用; 如果我们去掉了功能模块, 程序也可以正常链接, 只是扩展模块的功能将不起作用. |
符号修饰和函数签名
很久之前, 编译器编译源代码产生目标文件时, 符号名与相应的变量和函数的名字是一样的, 例如函数foo, 经过编译后对应的符号名也是foo, 那么久会产生冲突, 例如要使用Fortran语言编写的目标文件, 一链接就会报错. 为了解决这种冲突, 规定C语言的全局变量和函数经编译后, 符号名前加上_, 此时foo编译后符号名为_foo. 但是还是不能完全解决C语言源文件之间链接产生的问题, 因为大家都有下划线啊! 于是C++开始设计的时候就考虑到了这个问题, 衍生出了命名空间(Name Space).
在C++中, int func()和int func(int)和int func(float)是三个不一样的函数, 这里我们引用一个术语函数签名(Function Signature), 函数签名包括一个函数的信息, 包括函数名, 参数类型, 所在的类和命名空间等其他信息. 于是, 以上三个函数编译后各自的符号名均不一样但是有规律可循.
|
1 2 3 4 5 |
例如 : int func() -编译后-> _int_func_ int func(int) -编译后-> _int_func_int_ int func(float) -编译后-> _int_func_float_ // 这里只是举个栗子, 告诉大家他们的符号名不一致, 至于会变成什么样, 需要看是什么编译器 |
链接
很久很久以前, 人们把所有代码写在一个文件中, 到后来, 人类已经没有能力维护这个程序了. 于是人们把代码根据功能或性质划分为不同的模块. 于是, 将这些模块拼接起来的过程就叫 : 链接
不知道大家看完上述的编译过程有没有这么一个疑问 : 如果编译的时候编译器不知道一个外部符号的地址, 怎么办? 答案就是不管, 先放一边, 等到链接的时候再把地址修正, 这就是重定位该做的事.
链接过程包括 : 地址和空间分配(Address and Storage Allocation), 符号决议(Symbol Resolution) 和 重定位(Relocation).
静态链接
最基本的静态链接过程 : 把各个目标文件(.o文件)和库(Library)一起链接形成可执行文件.
那么他们每个文件中的段是怎么合并起来呢?
ELF用的就是相似段合并 : a的
GitHub : Jerry4me
前言
我们中有许多程序员打码几年还没有搞清楚一个程序从源代码 -> 可执行程序 -> 执行 -> 死亡, 经历了什么变化. 他们只知道, 编译, 链接, 运行…由于强大的IDE已经帮我们把这些过程屏蔽掉了, 我们不知道底层他们干了什么. 但是我们只有明白这些运行机制和机理, 才能解决一些莫名其妙的错误, 提升性能瓶颈.
笔者在看了>这本书后决定把这些过程用比较简单易懂的文字叙述出来, 如有不对的地方还请各位指出, 谢谢~
目录
预编译
编译
汇编
目标文件
链接
可执行文件
装载
动态链接(需要的话)
运行
死亡
小知识
编译
编译又分为 预处理(Preprocessing), 编译(Compilation)和汇编(Assembly).
预编译
预编译过程主要处理源代码文件那些#开头的预编译指令
|
1 2 3 4 5 6 7 8 |
1. 删除所有#define, 展开所有宏定义 2. 处理所有预编译指令, 如#if, #ifdef, #elif, #else, #endif 3. 递归处理#include 4. 删除所有注释, // 和 /**/ 5. 添加行号和文件名标识 6. 保留所有#pragma编译器指令 因此如果我们无法判断宏定义是否正确, 头文件包含是否正确时 -> 查看预编译后的文件来确定问题 |
编译
编译过程可分为6部 : 扫描, 语法分析, 语义分析, 源代码优化, 代码生成和目标代码优化.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
1. 扫描 : 扫描器运用一种类似于有限状态机的算法把源代码分割成一些列的记号(Token) 2. 语法分析 : 语法分析器采用上下文无关语法(Context-free Grammar)将Token进行语法分析, 生成语法树(Syntax Tree).该语法树就是以表达式为节点的树 3. 语义分析 : 语法分析只是对表达式的语法进行层面的分析, 它并不知道该语句是否真正有意义. 在这里, 语义分析器能够进行静态语义分析, 分析过后整个语法树的表达式都被标识了类型 静态语义 : 在编译器可以确定的语义, 通常包括声明和类型的匹配, 转换. 动态语义 : 在运行时才能确定的语义, 比如0作为除数则在这里报错 4. 源代码优化 : 源码级优化器(Source Code Optimizer)在源代码级别进行优化, 把一些类似于(2+6)这些在编译器就能确定的表达式优化成值, 从而把整个语法树转换成中间代码(Intermediate Code) 中间代码使得编译器可以被分为前端和后端, 前端负责产生机器无关的中间代码, 后端将中间代码转换成目标机器代码 5. 代码生成与优化 : 代码生成器(Code Generator)将中间代码转换成目标机器代码(该过程十分依赖于目标机器), 最后目标代码优化器(Target Code Optimizer)将上述的代码进行优化, 例如选择合适的寻址方式, 使用位移来代替乘法运算, 删除多余的指令等. |
汇编
汇编器将汇编代码转换成机器可以执行的指令, 输出目标文件. 该过程比较简单, 就是翻译代码.
经过上述多个步骤, 源代码终于被编译成了目标文件. 这个目标文件肚子里又卖的是什么药呢? 我们接着看~
目标文件
由于不同的操作系统下, 目标文件, 可执行文件等都有些出入. 本文是用Linux系统下的ELF文件作为例子
编译之后生成的目标文件内容肯定少不了机器指令代码, 数据等. 不过除了这些之外, 目标文件还包括了链接时所需的一些信息, 而目标文件将这些信息按照不同的属性, 以段(Section)来存储.
|
1 2 |
程序源代码编译后的机器指令 -> 代码段(Code Section), ".code"或".text" 全局变量和局部静态变量数据 -> 数据段(Data Section), ".data"或".bss" |
Question :
为什么要把数据和指令分开呢? 经典的冯诺依曼体系不是不分指令还是数据的吗?Answer :
1 : 当程序被装载后, 数据和指令被映射到两个虚存区域. 数据区域对于进程而言, 是可读写的, 而指令区域则只可读. 这样方便分别设置他们的权限, 防止程序指令被恶意修改
2 : 把指令和数据分开有利于提高程序的局部性, 对于提高CPU缓存命中率有帮助
3 : 最重要的原因, 当系统中运行着多个该程序的副本时, 他们的指令都是一样的, 所以进程之间能共享指令和其他只读数据, 而数据区域则为进程私有. 如果系统中运行了数百个进程, 可以想象共享为我们节省了多少空间
这里插一句 : 其实不是可执行文件才才按照执行文件的格式存储. 什么意思呢? 除了可执行文件之外, 目标对象, 动态链接库, 静态链接库也按照可执行文件的格式存储. 某种程度上他们也是可执行文件. 所以我们可以把他们视为同一类文件
目标文件有什么
ELF文件头(ELF Header)
包含了整个文件的基本属性
段表(Section Header Table)
描述了ELF文件包含的所有段的信息
重定位表
链接器在处理目标文件时, 要对目标文件中某些符号进行重定位, 即代码段和数据段那些对绝对地址引用的符号. 这些重定位信息就记录在重定位表中.
符号表
在链接中, 我们将函数和变量统称为符号(Symbol), 函数名和变量名称为符号名(Symbol Name). 符号表记录着该目标文件所用到的所有符号, 每个符号都有一个对应的值, 符号值(Symbol Value), 对于函数和变量来说, 符号值就是他们的地址.
强符号与弱符号, 强引用与弱引用
如果在目标文件A和目标文件B都定义了一个全局变量global, 并将他们都初始化. 那么链接的时候就会报multiple definition of 'global'的错误. 这种符号就是强符号. 默认所有符号都是强符号, 可以使用GCC的__attribute__ ((weak))定义一个弱符号.
强符号与弱符号的规则 :
|
1 2 3 |
1. 不允许多次定义强符号 2. 如果一个符号在某个目标文件中是强符号, 在其他目标文件中是弱符号, 那么链接时选择强符号 3. 如果一个符号在全部目标文件中都是弱符号, 那么选择占用空间最大的一个. |
符号引用被最终链接的时候必须要被正确决议, 如果没有找到该符号的定义, 就会报符号未定义错误undefined symbol of xxx, 这种称为强引用(Strong Reference). 而弱引用(Weak Reference)则被处理的时候如果未定义, 不报错, 链接器会默认其为0或者是一个特殊值. 默认都是强引用, 可以使用GCC的__attribute__ ((weakref))定义一个弱引用.
弱符号和弱引用的作用 :
|
1 2 3 4 |
对于库来说十分有用, 库中定义的弱符号可以被用户定义的强符号覆盖, 程序则可以使用自定义的库函数 或者程序可以对某些扩展功能模块的引用定义为弱引用, 当我们将扩展模块与程序链接在一起时, 功能模块可以正常使用; 如果我们去掉了功能模块, 程序也可以正常链接, 只是扩展模块的功能将不起作用. |
符号修饰和函数签名
很久之前, 编译器编译源代码产生目标文件时, 符号名与相应的变量和函数的名字是一样的, 例如函数foo, 经过编译后对应的符号名也是foo, 那么久会产生冲突, 例如要使用Fortran语言编写的目标文件, 一链接就会报错. 为了解决这种冲突, 规定C语言的全局变量和函数经编译后, 符号名前加上_, 此时foo编译后符号名为_foo. 但是还是不能完全解决C语言源文件之间链接产生的问题, 因为大家都有下划线啊! 于是C++开始设计的时候就考虑到了这个问题, 衍生出了命名空间(Name Space).
在C++中, int func()和int func(int)和int func(float)是三个不一样的函数, 这里我们引用一个术语函数签名(Function Signature), 函数签名包括一个函数的信息, 包括函数名, 参数类型, 所在的类和命名空间等其他信息. 于是, 以上三个函数编译后各自的符号名均不一样但是有规律可循.
|
1 2 3 4 5 |
例如 : int func() -编译后-> _int_func_ int func(int) -编译后-> _int_func_int_ int func(float) -编译后-> _int_func_float_ // 这里只是举个栗子, 告诉大家他们的符号名不一致, 至于会变成什么样, 需要看是什么编译器 |
链接
很久很久以前, 人们把所有代码写在一个文件中, 到后来, 人类已经没有能力维护这个程序了. 于是人们把代码根据功能或性质划分为不同的模块. 于是, 将这些模块拼接起来的过程就叫 : 链接
不知道大家看完上述的编译过程有没有这么一个疑问 : 如果编译的时候编译器不知道一个外部符号的地址, 怎么办? 答案就是不管, 先放一边, 等到链接的时候再把地址修正, 这就是重定位该做的事.
链接过程包括 : 地址和空间分配(Address and Storage Allocation), 符号决议(Symbol Resolution) 和 重定位(Relocation).
静态链接
最基本的静态链接过程 : 把各个目标文件(.o文件)和库(Library)一起链接形成可执行文件.
那么他们每个文件中的段是怎么合并起来呢?
ELF用的就是相似段合并 : a的.text合并, a的.data与b的.data合并, 其他段类似.
符号决议和重定位
符号地址的确定
重定位表
每个需要被重定位的段都有一个与之相对应的重定位表, 如.text段对应.rel.text
根据重定位表中每个符号的信息, 找到每个符号对应的目标对象文件, 再根据偏移(offset)确定其绝对地址(或相对地址).
动态链接
为什么有了静态链接还需要动态链接?
