更新2.2节

on-matching-binary-to-source-code.md

@@ -262,27 +262,27 @@ LBB0_6:
 
 之前介绍了软件构建过程的要点，现将二进制文件与复用的源码进行匹配的两个对立的想法结合进行讨论，以及讨论我们选择自动编译和自动解析的原因。
 
-####2.2.1 自动编译
+#### 2.2.1 自动编译
 
 二进制程序中识别重用源码的一个思路是，通过编译源码获得二进制译文，然后再利用二进制克隆检测技术。在该项目早期阶段，我们已探讨了这个思路，但是面临着几个重大的困难。据分析，任意一个源码的自动编译都面临着很大的实际挑战。在此，我们将列举和阐述一些自动编译的关键性障碍点，这也说明了直接比较源码和二进制文件的困难度。
 
-####2.2.1.1 多样的构建配置
+#### 2.2.1.1 多样的构建配置
 
 如2.1.1节所述，C代码在解析之前会进行预处理，这个过程会受到宏的极大影响，所以自动编译系统面临着为自定义预处理宏获取一组正确值的巨大挑战。通常，这些宏的某些值集合包含在代码库随附的配置脚本中，并在运行实际构建脚本之前运行。
 
 不同的工程使用不同的构建系统，这样就出现了各种各样的配置和构建方法。因此，不使用任何构建系统的知识，实际上是很难获得编译一段代码所需的宏。虽然[CMake[2]](https://cmake.org/)等现代构建系统提供了一种面向多个构建环境的跨平台方式，使构建过程高度标准化，但它们尚未被C/C++的代码库广泛采用。
 
-####2.2.1.2 外部依赖
+#### 2.2.1.2 外部依赖
 
 依靠外部库进行某些操作是非常常见的手法。这些外部依赖关系不一定包含在项目中，大多是需要自行下载，然后然后用兼容的方式编译。自动编译需要一个标准化的系统来检索和构建这些依赖关秀。这些依赖关系通常由构建自动化和依赖关系的管理脚本下载，或者由用户进行读取、安装。虽然标准依赖关系管理系统被其他语言广泛采用[[9](https://www.openhub.net/)，[35](https://pypi.python.org/pypi)，[57](https://maven.apache.org/)]，但C/C++项目尚未采用这种依赖关系管理系统，从而进一步阻碍了自动编译。
 
 
-####2.2.1.3 交叉编译
+#### 2.2.1.3 交叉编译
 
 在撰写本论文时(作者写论文的这个时期)，二进制克隆检测技术在应用于不同编译器、不同优化级别 不同的平台（如x86、ARM）等不同配置的二进制文件时通常是不可靠的[[31]]()。 另一方面，可能会有大量的候选工程通过搜索来运行。 在这种情况下，需要一个自动将所有源代码编译成二进制文件的解决方案，理想情况是使用不同的编译器和不同级别的优化。若某二进制文件的底层平台也未知，那就应该在不同的平台上构建项目，从中获取一个优质的二进制文件来匹配。
 
 
-###2.2.2 自动解析
+### 2.2.2 自动解析
 
 综上所述，我们不希望将目标源码编译成二进制文件，而是首先将源码和二进制文件做比较。因此，我们通过解析源码并遍历AST来提取关键特性，然后用于匹配。显然，自定义配置宏仍然是一个问题。但是，当只考虑AST创建时，创建机器执行码会出现问题，这是缺少关于宏的内容导致的，而不是阻塞引起的。在第五章，我们将以完全自动化的方式来解释获取AST的方法，无需访问预定义的自定义宏和头文件的位置。