本文简单介绍部分Clang和LLVM的编译命令。更关注前端部分（生成 IR 部分）。

1. Clang编译步骤概览

我们可以使用命令打印出来Clang支持的步骤，如下：

clang -ccc-print-phases test.c
            +- 0: input, "test.c", c
         +- 1: preprocessor, {0}, cpp-output
      +- 2: compiler, {1}, ir
   +- 3: backend, {2}, assembler
+- 4: assembler, {3}, object
5: linker, {4}, image

根据上面的介绍，可以根据每一部分的结果，分为5个步骤（不包含上面的第0步）：preprocessor、compiler、backend、assembler、linker等。

具体到 Clang 中每一步骤生成的结果文件。我们可以使用下面的示意图来表示：

说明：上面的示意图以Clang编译一个C文件为例，介绍了Clang编译过程中涉及到的中间文件类型：

(1) test.c 为输入的源码（对应步骤 0）；

(2) test.i 为预处理文件（对应步骤 1 的输出，cpp-output 中，cpp 不是指 C++ 语言，而是 c preprocessor 的 缩写）；

(3) test.bc 为 bitcode文件，是clang的一种中间表示（对应步骤 2 的输出）；

(4) test.ll 为一种文本化的中间表示，可以打开来看的（对应步骤 2 的输出， 和 .bc 一样都是中间表示，可以相互转化）；

(5) test.s 为汇编结果（对应步骤 3 的输出）；

(6) test.o 为单文件生成的二进制文件（对应步骤 4 的输出）；

(7) image 为可执行文件（对应步骤 5 的输出）。

注意：示意图画的也并不完整，如下介绍：

(1) 箭头所指的方向，表示可以从一种类型的文件，生成箭头所指的文件类型；

(2) 图中箭头并没有画完，比如可以从 test.c 生成 test.s, test.o 等。如果将上面的示意图当做一种 有向图，那么基于 箭头 所指的方向，只要 节点能连接的点，都是可以做转换的；

(3) 图中的实线和虚线，只是表示本人关心的Clang编译器中的内容，并没有其他的含义，本文也只介绍图中实线部分的内容，虚线部分的内容不做介绍。

2. 转换命令集合

下面介绍部分涉及到上面步骤的转换命令：

# 1. .c -> .i
clang -E -c test.c -o test.i

# 2. .c -> .bc
clang -emit-llvm test.c -c -o test.bc

# 3. .c -> .ll
clang -emit-llvm test.c -S -o test.ll

# 4. .i -> .bc
clang -emit-llvm test.i -c -o test.bc

# 5. .i -> .ll
clang -emit-llvm test.i -S -o test.ll

# 6. .bc -> .ll
llvm-dis test.bc -o test.ll

# 7. .ll -> .bc
llvm-as test.ll -o test.bc

# 8. 多 bc 合并为一个 bc
llvm-link test1.bc test2.bc -o test.bc

上面列出了一部分Clang不同文件直接转换的命令（和第 1 部分的 示意图 序号匹配，还是只关心前端部分）。只是最后增加了一个将多个 bc 合并为一个 bc file 的命令。

3. 查看Clang AST结构

我们可以通过如下的命令查看源码的AST结构：

clang -Xclang -ast-dump -c test.c

打印出来的AST信息，其实是预处理之后展开的源码信息，源码的AST内容在打印出来的内容的最下面。

如下面的代码：

#include <stdio.h>

int main() {
    printf("hello");
    return 0;
}

打印出来的部分AST（仅根当前文件内容匹配部分）如下：

头上的头文件引用等已经展开，没有了，但是下面的 main 函数定义，则如上面的 FunctionDecl 所示，并且给出了 代码中的位置。这里就不详细分析AST的结构了，写几个例子比对一下就很容易理解。

4. 编译正确性的影响因素

当前，很多静态代码分析工具，都采用 Clang 和 LLVM 作为底座来开发静态代码分析工具。Clang自己也有 clang-tidy 工具可以用来做 C/C++ 语言的静态代码分析。为了能够用 Clang 和 LLVM 来成功分析 C/C++ 代码，需要考虑如何成功使用 Clang 和 LLVM 来编译 C/C++ 代码。可以考虑的是，成功生成 bc file，是静态代码分析的基础操作。

4.1 影响预处理结果的因素

预处理过程，作用跟名字一样，都可以不当做编译的一个步骤，而是编译的一个预处理操作。我们说得再直白一点儿，其实就是做了一个文本替换的活儿，就是对 C/C++ 代码中的 预处理指令 进行处理。预处理指令很简单，比如 #include，#define 等，都是预处理指令（可以参考：https://docs.microsoft.com/en-us/cpp/preprocessor/preprocessor-directives?view=msvc-170，或者google下，很多介绍的）。

如果程序中没有预处理指令，即使我们随便瞎写的代码，预处理也一般不会有问题，如下的代码（main.c）：

abc
def

我们仍然可以正确得到 预处理结果：

# 1 "main.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 341 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "main.c" 2
abc
def

为了成功执行预处理执行，很容易理解，就是可以对程序中的所有的 预处理指令 进行处理。比如：

(1) #include，依赖了一个头文件，我们能不能成功找到这个头文件；

(2) #define，定义了一个宏，在程序中定义宏的时候，我们能不能准确找到宏（找到，还必须准确）；

(3) 其他指令。

4.2 影响IR生成因素

这一步是针对上一步生成的预处理指令，进行解析的操作。这一步才是最关键的，归根结底，我们需要保证一点：使Clang编译器可以正确识别出来代码中内容表示的语法结构，并且接纳这种语法结构！

举一些简单例子：

(1) -std 用来指定支持的 C/C++ 标准的，如果我们没有指定，那么就会采用 Clang 默认的标准来编译，就可能导致语法不兼容；

(2) -Werror=* 等参数，可能将某些能识别的语法，给搞成错误的使用；

(3) 其他的部分，跟语法识别的参数；

(4) 还有一部分的语法，可能 Clang 自始至终就没有进行适配，这种就要考虑修改源码了。

4.3 链接相关因素

在真正编译中，如果链接有问题，那就会失败，但是在静态代码分析中，链接有失败（无法链接）或者错误（不相关的给链接在一起），可能多点儿分析误报或者漏报，一般不会导致分析失败。这类问题，影响的不是中间表示的生成，而是分析结果（影响跨文件的过程间分析，影响对built-in函数的建模等）。

一般，链接命令的捕获，target信息配置等，会影响这部分的能力。当然，也跟你实现的工具有关（如果实现的工具，就没有跨文件的能力，这部分内容也没啥影响）。