4

一文带你梳理Clang编译步骤及命令

 2 years ago
source link: https://my.oschina.net/u/4526289/blog/5375759
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

摘要: 本文简单介绍了Clang编译过程中涉及到的步骤和每个步骤的产物,并简单分析了部分影响预处理和编译成功的部分因素。

本文分享自华为云社区《Clang编译步骤及命令梳理》,作者:maijun。

本文简单介绍部分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 中每一步骤生成的结果文件。我们可以使用下面的示意图来表示:

v2-15d13d5b18dc0aa8477189ef24f6cf8d_720w.jpg

说明:上面的示意图以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(仅根当前文件内容匹配部分)如下:

v2-5df3e16bc9bc5e1dc2f1ec99e11442e5_720w.jpg

头上的头文件引用等已经展开,没有了,但是下面的 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信息配置等,会影响这部分的能力。当然,也跟你实现的工具有关(如果实现的工具,就没有跨文件的能力,这部分内容也没啥影响)。

点击关注,第一时间了解华为云新鲜技术~


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK