iOS 查漏补缺 - LLVM & Clang

iOS 查漏补缺 - LLVM & Clang_第1张图片
iOS 查漏补缺 - LLVM&Clang.png

LLVM 是一个自由软件项目,它是一种编译器基础设施,以 C++ 写成,包含一系列模块化的编译器组件和工具链,用来开发编译器前端和后端。它是为了任意一种编程语言而写成的程序,利用虚拟技术创造出编译时期、链接时期、运行时期以及“闲置时期”的最优化。它最早以 C/C++ 为实现对象,而当前它已支持包括 ActionScript、Ada、D语言、Fortran、GLSL、Haskell、Java字节码、Objective-C、Swift、Python、Ruby、Crystal、Rust、Scala 以及 C# 等语言。

-- 维基百科

2000年,伊利诺伊大学厄巴纳-香槟分校(University of Illinois at Urbana-Champaign 简称UIUC)这所享有世界声望的一流公立研究型大学的 Chris Lattner(他的 twitter @clattner_llvm ) 开发了一个叫作 Low Level Virtual Machine 的编译器开发工具套件,后来涉及范围越来越大,可以用于常规编译器,JIT编译器,汇编器,调试器,静态分析工具等一系列跟编程语言相关的工作,于是就把简称 LLVM 这个简称作为了正式的名字。Chris Lattner 后来又开发了 Clang,使得 LLVM 直接挑战 GCC 的地位。2012年,LLVM 获得美国计算机学会 ACM 的软件系统大奖,和 UNIX,WWW,TCP/IP,Tex,JAVA 等齐名。

-- 深入剖析 iOS 编译 Clang / LLVM

对于 iOS 开发者来说,Swift 之父 Chris Lattner 的大名应该都会有所耳闻。他和他的团队所开发的 LLVM 已经成为 iOS 乃至 macOS 整个生态中至关重要的底层基础设施。虽然 Lattner 本人已经去 Google 做人工智能了,但是对于 iOS 开发者了解并掌握一些关于 LLVM 的基本知识还是很有必要的。

LLVM 初探

LLVM 的官网是 http://llvm.org/。通过官网我们可以看到,LLVM 其实是一系列的编译组件的集合。而 Clang (标准读法是 克朗) 是作为其中的前端。这里的前端并不是 HTML5 这样的前端概念。说到这里,我们来简单回顾下传统编译器的设计吧。

传统编译器

在 LLVM 诞生之前,使用最广泛的应该是 GCC 编译器了,当然,GCC 在当下仍然扮演着很重要的角色。

iOS 查漏补缺 - LLVM & Clang_第2张图片
image

编译器前端 Front End

编译器前端的任务是解析源代码,具体工作内容包括下列三个流程

  • 词法分析
  • 语法分析
  • 语义分析

检查源代码是否存在错误,然后构建抽象语法树(Abstract Syntax Tree, AST)。
LLVM的前端还会生成中间代码(intermediate representation, IR)。

优化器 Optimizer

优化器负责进行各种优化。改善代码的运行时间,例如消除冗余计算等。

编译器后端 Back End

将代码映射到目标指令集。生成机器语言,并且进行机器相关的代码优化。
有些资料也会把编译器后端成为 代码生成器 Code Generator。

从上面的内容可以看到,传统的编译器架构前端和后端之间耦合度太高,如果要支持一门新的编程语言,或者一个新的目标平台,工作量会非常大。

LLVM 架构

LLVM 之所以能够成为编译器中的中流砥柱,最重要的就是使用了通用的代码表现形式,也就是 IR。有了 IR,LLVM 就可以为任何编程语言独立编写前端,并且可以为任意硬件架构独立编写后端。

iOS 查漏补缺 - LLVM & Clang_第3张图片
LLVM Design

LLVM 架构概述

Clang

Clang 是 LLVM 项目中的一个子项目。它是基于 LLVM 架构的轻量级编译器,诞生之初是为了替代 GCC,提供更快的编译速度。它是负责编译 C、C++、Objective-C 语言的编译器,它属于整个 LLVM 架构中的编译器前端。对于我们来说,研究 Clang 可以让我们更深刻的理解从源码到汇编再到机器码的这一过程。

Clang 的官网地址是 http://clang.llvm.org/

相比于 GCC,Clang 具有以下优点

  • 编译速度快:在某些平台上,Clang的编译速度显著的快过GCC(Debug模式下编译OC速度比GGC快3倍)
  • 占用内存小:Clang生成的AST所占用的内存是GCC的五分之一左右
  • 模块化设计:Clang采用基于库的模块化设计,易于 IDE 集成及其他用途的重用
  • 诊断信息可读性强:在编译过程中,Clang 创建并保留了大量详细的元数据 (metadata),有利于调试和错误报告
  • 设计清晰简单,容易理解,易于扩展增强

也就是说,广义上的 LLVM 指的是整个 LLVM 架构,而狭义上的 LLVM 是指的 LLVM 后端。
而 LLVM 后端包括代码优化(优化器)和目标代码生成(后端)两个部分。

iOS 查漏补缺 - LLVM & Clang_第4张图片
image.png

iOS 中的编译过程

在探索编译过程之前,我们先通过一个命令来打印出源码的编译阶段

clang -ccc-print-phases 文件名

打印输出如下

0: input, "main.m", objective-c
1: preprocessor, {0}, objective-c-cpp-output
2: compiler, {1}, ir
3: backend, {2}, assembler
4: assembler, {3}, object
5: linker, {4}, image
6: bind-arch, "x86_64", {5}, image

从结果可以看到,一共分为 7 大阶段。

  • input: 输入阶段,表示将 main.m 文件输入,文件格式是 OC
  • preprocessor: 预处理阶段,这个过程包括宏的替换,头文件的导入
  • compiler:编译阶段,进行词法分析、语法分析、语义分析,最终生成 IR
  • backend: 后端,LLVM 会通过一个一个的 Pass 去优化,最终生成汇编代码。
  • assembler: 汇编,生成目标文件
  • linker: 链接,链接需要的动态库和静态库,生成可执行文件
  • bind-arch: 架构绑定,通过不同的架构,生成对应的可执行文件

预处理阶段

clang -E 文件名 -o 输出文件名

我们可以通过上面的 clang 命令来执行预处理阶段并输出到一个文件中。

我们可以测试一下,在 main.m 中代码如下

// main.m
#include 

#define C 30
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        int a = 10;
        int b = 20;
        printf("%d", a + b + C);
    }
    return 0;
}

然后执行

clang -E main.m -i main2.m

可以查看一下 main2.m 文件的内容:

iOS 查漏补缺 - LLVM & Clang_第5张图片
image

可以看到,宏已经被替换了,并且 stdio.h 头文件也被导入进来了。

那像 typedef 这样的命令是否也会在预处理阶段被替换了,我们可以测试一下:

#include 

#define C 30
typedef int JH_INT_64;
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        JH_INT_64 a = 10;
        JH_INT_64 b = 20;
        printf("%d", a + b + C);
    }
    return 0;
}

还是执行同样的命令

clang -E main.m -o main3.m

结果如下

iOS 查漏补缺 - LLVM & Clang_第6张图片
image

可以看到,typedef 并没有被替换掉,原因在于 typedef 只是一个别名,并不属于宏定义的范畴。

编译阶段

经过预处理阶段之后,源文件需要被编译生成相应的中间代码 IR。
但我们知道其实整个编译阶段是分为 词法分析语法分析 两个阶段。

词法分析

预处理完成后就会进行词法分析,代码会被切成一个个 Token,比如大小括号,等于号和字符串。

词法分析命令如下

clang -fmodules -fsyntax-only -Xclang -dump-tokens 文件名

我们测试一下

clang -fmodules -fsyntax-only -Xclang -dump-tokens main.m

终端输出结果如下

annot_module_include '#include 

#define C 30
typedef int JH_INT_64;
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        JH_INT_64 a '       Loc=
typedef 'typedef'    [StartOfLine]  Loc=
int 'int'    [LeadingSpace] Loc=
identifier 'JH_INT_64'   [LeadingSpace] Loc=
semi ';'        Loc=
int 'int'    [StartOfLine]  Loc=
identifier 'main'    [LeadingSpace] Loc=
l_paren '('     Loc=
int 'int'       Loc=
identifier 'argc'    [LeadingSpace] Loc=
comma ','       Loc=
const 'const'    [LeadingSpace] Loc=
char 'char'  [LeadingSpace] Loc=
star '*'     [LeadingSpace] Loc=
identifier 'argv'    [LeadingSpace] Loc=
l_square '['        Loc=
r_square ']'        Loc=
r_paren ')'     Loc=
l_brace '{'  [LeadingSpace] Loc=
at '@'   [StartOfLine] [LeadingSpace]   Loc=
identifier 'autoreleasepool'        Loc=
l_brace '{'  [LeadingSpace] Loc=
identifier 'JH_INT_64'   [StartOfLine] [LeadingSpace]   Loc=
identifier 'a'   [LeadingSpace] Loc=
equal '='    [LeadingSpace] Loc=
numeric_constant '10'    [LeadingSpace] Loc=
semi ';'        Loc=
identifier 'JH_INT_64'   [StartOfLine] [LeadingSpace]   Loc=
identifier 'b'   [LeadingSpace] Loc=
equal '='    [LeadingSpace] Loc=
numeric_constant '20'    [LeadingSpace] Loc=
semi ';'        Loc=
identifier 'printf'  [StartOfLine] [LeadingSpace]   Loc=
l_paren '('     Loc=
string_literal '"%d"'       Loc=
comma ','       Loc=
identifier 'a'   [LeadingSpace] Loc=
plus '+'     [LeadingSpace] Loc=
identifier 'b'   [LeadingSpace] Loc=
plus '+'     [LeadingSpace] Loc=
numeric_constant '30'    [LeadingSpace] Loc=>
r_paren ')'     Loc=
semi ';'        Loc=
r_brace '}'  [StartOfLine] [LeadingSpace]   Loc=
return 'return'  [StartOfLine] [LeadingSpace]   Loc=
numeric_constant '0'     [LeadingSpace] Loc=
semi ';'        Loc=
r_brace '}'  [StartOfLine]  Loc=
eof ''      Loc=

可以看到,main.m 中的代码都被拆解成了一个一个 token。

语法分析

词法分析完成之后就是语法分析。它的任务是验证语法是否正确。在词法分析的基础上将单词序列组合成各类词法短语。如 程序、语句、表达式等,然后将所有的节点组成抽象语法树(Abstract Syntax Tree, AST)。

语法分析命名如下

clang -fmodules -fsyntax-only -Xclang -ast-dump 文件名

我们测试一下

clang -fmodules -fsyntax-only -Xclang -ast-dump main.m

终端打印结果如下

TranslationUnitDecl 0x7fa0aa017408 <> 
|-TypedefDecl 0x7fa0aa017ca0 <>  implicit __int128_t '__int128'
| `-BuiltinType 0x7fa0aa0179a0 '__int128'
|-TypedefDecl 0x7fa0aa017d08 <>  implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x7fa0aa0179c0 'unsigned __int128'
|-TypedefDecl 0x7fa0aa017da0 <>  implicit SEL 'SEL *'
| `-PointerType 0x7fa0aa017d60 'SEL *'
|   `-BuiltinType 0x7fa0aa017c00 'SEL'
|-TypedefDecl 0x7fa0aa017e78 <>  implicit id 'id'
| `-ObjCObjectPointerType 0x7fa0aa017e20 'id'
|   `-ObjCObjectType 0x7fa0aa017df0 'id'
|-TypedefDecl 0x7fa0aa017f58 <>  implicit Class 'Class'
| `-ObjCObjectPointerType 0x7fa0aa017f00 'Class'
|   `-ObjCObjectType 0x7fa0aa017ed0 'Class'
|-ObjCInterfaceDecl 0x7fa0aa017fa8 <>  implicit Protocol
|-TypedefDecl 0x7fa0aa0182e8 <>  implicit __NSConstantString 'struct __NSConstantString_tag'
| `-RecordType 0x7fa0aa018100 'struct __NSConstantString_tag'
|   `-Record 0x7fa0aa018070 '__NSConstantString_tag'
|-TypedefDecl 0x7fa0aa018380 <>  implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x7fa0aa018340 'char *'
|   `-BuiltinType 0x7fa0aa0174a0 'char'
|-TypedefDecl 0x7fa0aa054e68 <>  implicit __builtin_va_list 'struct __va_list_tag [1]'
| `-ConstantArrayType 0x7fa0aa054e10 'struct __va_list_tag [1]' 1
|   `-RecordType 0x7fa0aa054c90 'struct __va_list_tag'
|     `-Record 0x7fa0aa054c00 '__va_list_tag'
|-ImportDecl 0x7fa0aa055670  col:1 implicit Darwin.C.stdio
|-TypedefDecl 0x7fa0aa0556c0  col:13 referenced JH_INT_64 'int'
| `-BuiltinType 0x7fa0aa017500 'int'
|-FunctionDecl 0x7fa0aa055980  line:13:5 main 'int (int, const char **)'
| |-ParmVarDecl 0x7fa0aa055728  col:14 argc 'int'
| |-ParmVarDecl 0x7fa0aa055840  col:33 argv 'const char **':'const char **'
| `-CompoundStmt 0x7fa0aa1dc880 
|   |-ObjCAutoreleasePoolStmt 0x7fa0aa1dc838 
|   | `-CompoundStmt 0x7fa0aa1dc810 
|   |   |-DeclStmt 0x7fa0aa055b60 
|   |   | `-VarDecl 0x7fa0aa055ae0  col:19 used a 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa055b40  'int' 10
|   |   |-DeclStmt 0x7fa0aa1dc5d0 
|   |   | `-VarDecl 0x7fa0aa055b88  col:19 used b 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa1dc200  'int' 20
|   |   `-CallExpr 0x7fa0aa1dc7b0  'int'
|   |     |-ImplicitCastExpr 0x7fa0aa1dc798  'int (*)(const char *, ...)' 
|   |     | `-DeclRefExpr 0x7fa0aa1dc5e8  'int (const char *, ...)' Function 0x7fa0aa1dc228 'printf' 'int (const char *, ...)'
|   |     |-ImplicitCastExpr 0x7fa0aa1dc7f8  'const char *' 
|   |     | `-ImplicitCastExpr 0x7fa0aa1dc7e0  'char *' 
|   |     |   `-StringLiteral 0x7fa0aa1dc648  'char [3]' lvalue "%d"
|   |     `-BinaryOperator 0x7fa0aa1dc748  'int' '+'
|   |       |-BinaryOperator 0x7fa0aa1dc708  'int' '+'
|   |       | |-ImplicitCastExpr 0x7fa0aa1dc6d8  'JH_INT_64':'int' 
|   |       | | `-DeclRefExpr 0x7fa0aa1dc668  'JH_INT_64':'int' lvalue Var 0x7fa0aa055ae0 'a' 'JH_INT_64':'int'
|   |       | `-ImplicitCastExpr 0x7fa0aa1dc6f0  'JH_INT_64':'int' 
|   |       |   `-DeclRefExpr 0x7fa0aa1dc6a0  'JH_INT_64':'int' lvalue Var 0x7fa0aa055b88 'b' 'JH_INT_64':'int'
|   |       `-IntegerLiteral 0x7fa0aa1dc728  'int' 30
|   `-ReturnStmt 0x7fa0aa1dc870 
|     `-IntegerLiteral 0x7fa0aa1dc850  'int' 0
`-

在执行语法分析命令的时候,如果有引入 iOS 相关的头文件,则需要加入指定的 SDK 路径来避免执行失败

如下面的命令所示,指定了 iOS 13.2 模拟器的 SDK的路径。

clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk -fmodules -fsyntax-only -Xclang -ast-dump main.m

AST 抽象语法树输出之后是一个很明显的树状结构,阅读起来其实并不困难。

|-FunctionDecl 0x7fa0aa055980  line:13:5 main 'int (int, const char **)'
  • 开头的 FunctionDecl 表示是一个函数声明节点。后面跟了一个内存地址,就其实是栈空间内的函数的地址。尖括号里面的内容表示是 main 函数的起始范围,从第 13 行的第 1 个字符开始,到第 20 行的第 1 个字符结束。然后后面的 line:13:5 表示从第 13 行的第 5 个字符开始是函数的参数声明区域。
| |-ParmVarDecl 0x7fa0aa055728  col:14 argc 'int'
| |-ParmVarDecl 0x7fa0aa055840  col:33 argv 'const char **':'const char **'
  • 这两个节点类型为 ParmVarDecl,表示的是参数节点,其中第一个参数 argc 是 int 类型,第二个参数 argv 是 const char** 类型。
|   `-CallExpr 0x7fa0aa1dc7b0  'int'
  • CallExpr 表示的是调用某个函数。后面的 int 表示调用函数的返回值。这里其实就是源码中 printf 函数的位置。
|   |   |-DeclStmt 0x7fa0aa055b60 
|   |   | `-VarDecl 0x7fa0aa055ae0  col:19 used a 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa055b40  'int' 10
|   |   |-DeclStmt 0x7fa0aa1dc5d0 
|   |   | `-VarDecl 0x7fa0aa055b88  col:19 used b 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa1dc200  'int' 20
  • DeclStmt 表示的是声明语句节点,这里很容易就能看出声明了两个 int 类型的变量,一个值为 10,一个值为 20。
|   |     |-ImplicitCastExpr 0x7fa0aa1dc798  'int (*)(const char *, ...)' 
|   |     | `-DeclRefExpr 0x7fa0aa1dc5e8  'int (const char *, ...)' Function 0x7fa0aa1dc228 'printf' 'int (const char *, ...)'
|   |     |-ImplicitCastExpr 0x7fa0aa1dc7f8  'const char *' 
|   |     | `-ImplicitCastExpr 0x7fa0aa1dc7e0  'char *' 
|   |     |   `-StringLiteral 0x7fa0aa1dc648  'char [3]' lvalue "%d"
  • ImplicitCastExpr 表示隐式转换表达式节点,说明 printf 函数其实前面还有隐式转换的操作: int (*)(const char *, ...)
  • 最后一行显然就是 printf 函数的开头位置的 %d,表示接收一个 int 类型的值。
|   |     `-BinaryOperator 0x7fa0aa1dc748  'int' '+'
|   |       |-BinaryOperator 0x7fa0aa1dc708  'int' '+'
|   |       | |-ImplicitCastExpr 0x7fa0aa1dc6d8  'JH_INT_64':'int' 
|   |       | | `-DeclRefExpr 0x7fa0aa1dc668  'JH_INT_64':'int' lvalue Var 0x7fa0aa055ae0 'a' 'JH_INT_64':'int'
|   |       | `-ImplicitCastExpr 0x7fa0aa1dc6f0  'JH_INT_64':'int' 
|   |       |   `-DeclRefExpr 0x7fa0aa1dc6a0  'JH_INT_64':'int' lvalue Var 0x7fa0aa055b88 'b' 'JH_INT_64':'int'
|   |       `-IntegerLiteral 0x7fa0aa1dc728  'int' 30
  • BinaryOperator 表示的是二元运算符。这里阅读的方式应该是先看叶子节点,所以翻译过来就是 (a + b) + 30 的结果作为 printf 函数的入参。
|   `-ReturnStmt 0x7fa0aa1dc870 
|     `-IntegerLiteral 0x7fa0aa1dc850  'int' 0
  • ReturnStmt 表示的是函数返回声明节点。显示返回的结果是 int 类型 0。

生成中间代码 IR

完成上面的步骤之后就可以生成中间代码 IR 了,代码生成器会将语法树自顶向下遍历逐步翻译成 LLVM IR。

LLVM IR 有三种表现形式,但本质上是等价的,就好比水可以有气体、液体、固体 3 种形态。

  • text :便于阅读的文本格式,类似于汇编语言,拓展名为 ll。
// 生成 text 格式的 IR
clang -S -fobjc-arc -emit-llvm 文件名
  • memory :内存格式
  • bitcode :二进制格式,拓展名为 .bc
// 生成 bitcode 格式的 IR
clang -c -fobjc-arc -emit-llvm 文件名

IR 基本语法:

@ 全局标识
% 局部标识
alloca 开辟空间
align 内存对齐
i32 32 bit, 即 4 个字节
store 写入内存
load 读取数据
call 调用函数
ret 返回

下面我们实际测试一下

// main.m
#include 

int test(int a, int b) {
    return a + b + 3;
}

int main(int argc, const char* argv[]) {
    int a = test(1, 2);
    printf("%d", a);
    return 0;
}

main.m 文件内容如上,接着我们在终端执行

clang -S -fobjc-arc -emit-llvm main.m

然后会生成一个 main.ll 文件,截取部分代码如下

; Function Attrs: noinline nounwind optnone ssp uwtable
define i32 @test(i32, i32) #0 {
  %3 = alloca i32, align 4
  %4 = alloca i32, align 4
  store i32 %0, i32* %3, align 4
  store i32 %1, i32* %4, align 4
  %5 = load i32, i32* %3, align 4
  %6 = load i32, i32* %4, align 4
  %7 = add nsw i32 %5, %6
  %8 = add nsw i32 %7, 3
  ret i32 %8
}

; Function Attrs: noinline optnone ssp uwtable
define i32 @main(i32, i8**) #1 {
  %3 = alloca i32, align 4
  %4 = alloca i32, align 4
  %5 = alloca i8**, align 8
  %6 = alloca i32, align 4
  store i32 0, i32* %3, align 4
  store i32 %0, i32* %4, align 4
  store i8** %1, i8*** %5, align 8
  %7 = call i32 @test(i32 1, i32 2)
  store i32 %7, i32* %6, align 4
  %8 = load i32, i32* %6, align 4
  %9 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str, i32 0, i32 0), i32 %8)
  ret i32 0
}

我们先看 main 方法,可以看到 main 方法里面有两处 call 的使用,分别对应了 main.m 中对 test() 方法和 print 方法的调用。接着我们看 test 方法在 IR 中的表现:

// IR
define i32 @test(i32, i32)

// main.m
int test(int a, int b) 
  • 这一行等价于 int test(int a, int b)。第一个 i32 表示函数的返回值,第二个和第三个 i32 表示函数参数。这里其实有两个隐藏的标识 %0 和 %1 ,分别表示参数 a 和 b。
 %3 = alloca i32, align 4
 %4 = alloca i32, align 4
  • 分配 4 个字节内存空间,并以 4 字节对齐,返回给 %3 标识
  • 分配 4 个字节内存空间,并以 4 字节对齐,返回给 %4 标识
store i32 %0, i32* %3, align 4
store i32 %1, i32* %4, align 4
  • 将 %0 标识中内容取出,存入 %3 标识的内存空间,并以 4 字节对齐
  • 将 %1 标识中内容取出,存入 %4 标识的内存空间,并以 4 字节对齐
%5 = load i32, i32* %3, align 4
%6 = load i32, i32* %4, align 4
  • 将 %3 标识中内容取出,存入 %5 标识的内存空间,并以 4 字节对齐
  • 将 %4 标识中内容取出,存入 %6 标识的内存空间,并以 4 字节对齐
%7 = add nsw i32 %5, %6
%8 = add nsw i32 %7, 3
  • 将 %5 和 %6 标识相加,结果赋值给 %7 标识
  • 将 %7 标识和 3 相加,结果赋值给 %8 标识
ret i32 %8
  • 返回 %8 标识的内容

上面这一系列操作其实等价于 main.m 中 test 函数的内容: return a + b + 3;
但是在 IR 中间代码中,这一行代码被转换成了更多的步骤,其实,这里是因为执行生成 IR 代码的命令默认是没有开启优化的,我们可以在 XCode 中查看在 Debug 和 Release 模式下对应的优化级别:

iOS 查漏补缺 - LLVM & Clang_第7张图片
image

优化级别从低到高分为:

  • None: Debug 模式的默认选项,没有优化。标识符为 -O0
  • Fast: 标识符为 -O, O1
  • Faster: 标识符为 -O2
  • Fastest: 标识符为 -O3
  • Fastest, Smallest: 标识符为 -Os
  • Fastest, Aggressive Optimizations: 标识符为 -Ofast
  • Smallest, Aggressive Size Optimizations: 标识符为 -Oz

比如,我们采取 Fastest, Smallest 优化策略,在终端可以这样输入

clang -Os -S -fobjc-arc -emit-llvm main.m -o main1.ll

截取 main1.ll 部分内容如下

; Function Attrs: norecurse nounwind optsize readnone ssp uwtable
define i32 @test(i32, i32) local_unnamed_addr #0 {
  %3 = add i32 %0, 3
  %4 = add i32 %3, %1
  ret i32 %4
}

; Function Attrs: nounwind optsize ssp uwtable
define i32 @main(i32, i8** nocapture readnone) local_unnamed_addr #1 {
  %3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str, i64 0, i64 0), i32 6) #3, !clang.arc.no_objc_arc_exceptions !9
  ret i32 0
}

可以看到 IR 的代码行数被大大压缩了。并且在 main 方法里面,直接算出了 test 函数的执行结果为 6,而省略了对 test 函数的调用。

生成汇编代码

通过最终的 bc 或者 ll 中间代码生成汇编代码

// ll 生成汇编
clang -S -fobjc-arc main.ll -o main.s

// bc 生成汇编
clang -S -fobjc-arc main.bc -o main.s

生成汇编代码也可以采用优化策略

clang -Os -S -fobjc-arc 中间代码IR -o 汇编源文件

我们测试一下

clang -Os -S -fobjc-arc main.ll -o main.s

输出的汇编源文件 main.s 内容如下:

    .section    __TEXT,__text,regular,pure_instructions
    .build_version macos, 10, 15    sdk_version 10, 15
    .globl  _test                   ## -- Begin function test
    .p2align    4, 0x90
_test:                                  ## @test
    .cfi_startproc
## %bb.0:
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register %rbp
    movl    %edi, -4(%rbp)
    movl    %esi, -8(%rbp)
    movl    -4(%rbp), %esi
    addl    -8(%rbp), %esi
    addl    $3, %esi
    movl    %esi, %eax
    popq    %rbp
    retq
    .cfi_endproc
                                        ## -- End function
    .globl  _main                   ## -- Begin function main
    .p2align    4, 0x90
_main:                                  ## @main
    .cfi_startproc
## %bb.0:
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register %rbp
    subq    $32, %rsp
    movl    $0, -4(%rbp)
    movl    %edi, -8(%rbp)
    movq    %rsi, -16(%rbp)
    movl    $1, %edi
    movl    $2, %esi
    callq   _test
    movl    %eax, -20(%rbp)
    movl    -20(%rbp), %esi
    leaq    L_.str(%rip), %rdi
    movb    $0, %al
    callq   _printf
    xorl    %esi, %esi
    movl    %eax, -24(%rbp)         ## 4-byte Spill
    movl    %esi, %eax
    addq    $32, %rsp
    popq    %rbp
    retq
    .cfi_endproc
                                        ## -- End function
    .section    __TEXT,__cstring,cstring_literals
L_.str:                                 ## @.str
    .asciz  "%d"

    .section    __DATA,__objc_imageinfo,regular,no_dead_strip
L_OBJC_IMAGE_INFO:
    .long   0
    .long   64


.subsections_via_symbols

生成目标文件

目标文件的生成,是汇编器以汇编代码作为输入,将汇编代码转换为机器代码, 最后输出目标文件。命令如下:

clang -fmodules -c 汇编源文件 -o 目标文件

我们测试一下

clang -fmodules -c main.s -o main.o

生成完目标文件之后,我们可以通过 nm 命令来查看符号情况

nm -nm main.o

// 输出
                 (undefined) external _printf
0000000000000000 (__TEXT,__text) external _test
0000000000000020 (__TEXT,__text) external _main

_prinf 是一个 undefined external 符号,其中 undefined 表示在当前文件暂时找不到符号 _prinf,而 external 表示这个符号是外部可以访问的。

生成可执行文件

链接器把编译产生的 .o 文件和库文件(动态库 .dylib, 静态库 .a)文件链接起来,生成了一个 Mach-O 可执行文件。

命令如下

clang 目标文件名 -o 可执行文件名

我们测试一下

clang main.o -o main

接着查看可执行文件中的符号情况

xcrun nm -nm main


                 (undefined) external _printf (from libSystem)
                 (undefined) external dyld_stub_binder (from libSystem)
0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header
0000000100000f20 (__TEXT,__text) external _test
0000000100000f40 (__TEXT,__text) external _main
0000000100002008 (__DATA,__data) non-external __dyld_private

可以看到 printf 函数的符号是从 libSystem 库中加载而来,说明系统函数是在运行时通过 dyld 去做符号绑定的。

编译 LLVM 工程

LLVM 下载

由于国内的网络限制,最好借助下面的镜像下载 LLVM 的源码
https://mirrors.tuna.tsinghua.edu.cn/help/llvm/

  • 下载 LLVM 项目
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/llvm.git
  • 在 LLVM 的 tools 目录下下载 Clang
cd llvm/tools
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang.git
  • 在 LLVM 的 projects目录下下载 compiler-rt, libcxx, libcxxabi
cd   ../projects
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/compiler-rt.g
it
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxx.git
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxxabi.git
  • 在 Clang 的 tools 下安装 extra 工具
cd ../tools/clang/tools
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang-tools-e
xtra.git

LLVM 编译

由于最新的 LLVM 只支持 cmake 编译,我们还需要安装 cmake

安装 cmake

  • 查看 brew 是否安装了 cmake,如果已经安装跳过这一步骤
brew list
  • 通过 brew 安装 cmake
brew install cmake

通过 Xcode 编译 LLVM

  • cmake 编译成 Xcode 项目
mkdir build_xcode
cd build_code
cmake -G Xcode ../llvm
  • 使用 Xcode 编译 Clang
    • 选择自动创建 Schemes


      iOS 查漏补缺 - LLVM & Clang_第8张图片
      image
    • 编译,选择 ALL_BUILD Scheme 进行编译,预计花费 1 个多小时

Clang 插件初探

编译完成后,我们可以基于 Clang 来定制属于我们自己的插件。

Clang 一共提供了三种不同的方式来编写:

  • LibClang: 稳定的高级C语言抽象接口
优点:
1.可以使用 C++ 之外的语言与clang交互.
2.有稳定的交互接口 & 向后兼容.
3.提供强大的高级抽象 例如通过cursor 迭代AST,&不用学习Clang‘s AST  详细知识.
缺点:
不能完全控制clang AST

ps:官方提供 c&python 形式API,这里有一个OC形式的 Clangkit

  • Clang Plugins:Clang 插件允许你在AST上添加运行其他操作作为编译的一部分。插件是由编译器在运行时加载的动态库,它们很容易集成到构建环境中。
使用Clang插件:
    1.如果任何依赖关系发生变化,则需要您的工具重新运行
    2.希望您的工具能够制作或打破构建
    3.需要完全控制Clang AST

不使用Clang插件:
    1.想要在构建环境之外运行工具
    2.想要完全控制Clang的设置,包括内存虚拟文件的映射
    3.需要在项目中运行特定的文件子集,而这些文件与触发重建的任何更改无关

ps:当你需要针对您的项目的特殊格式的警告或错误,或者从一个编译步骤创建额外的构建工件时,clang plugins 是你的不二之选。

  • LibTooling 是一个 C++ 接口,旨在编写独立工具,以及集成到运行clang工具的服务中。
使用LibTooling:
    1.希望独立于构建系统,在单个文件或特定文件子集上运行工具
    2.想要完全控制Clang AST
    3.想与Clang插件分享代码

不使用LibTooling:
    1.想要作为由依赖性更改触发的构建的一部分运行
    2.想要一个稳定的接口,以便在AST API更改时不需要更改代码
    3.希望使用像cursor这样的高级抽象
    4.不想用C ++编写你的工具

ps:当你需要写一个简单的语法检查器或者一个重构工具时,选择libTooling

我们现在的需求是能够在编译时检查属性标识符应该设置 copy 但是没有设置的情况,然后给出相应的警告提示信息。
所以我们的最佳方案就是 clang plugin, 我们看下它是如何执行的:

iOS 查漏补缺 - LLVM & Clang_第9张图片
image

具体是在动态库装载进来后,可以拿到我们自定义的 pluginAction(FrontendAction 的子类)。

然后在 CompileInstance 初始化之后,依次调用 pluginAction 的几个成员函数(BeginSourceFile、Excute、EndSourceFile)。

其中 CreateConsumer 创建我们自定义的 consumer 来获取语法树信息,执行ExecuteAction 函数进入 ParseAST 分析流程,调用我们自定义的 ASTConsumer 去handle,通过 RecursiveASTVisitor 或 ASTMatcher 来匹配想检查操作的AST Notes。

如果不符合规范的话,创建一个diagnosis 来警告或报错,并且可以创建一个 FixHint 来提供修复能力。期间通过 ASTContext 及其关联的 SourceManager 获取源码位置&全局标识符等信息。

上述的 ParseAST 阶段,推荐使用 ASTMatcher,可以简单、精准、高效的匹配到AST Notes。

创建插件

  • /llvm/tools/clang/tools 目下新建插件的文件夹
image
  • 修改 /llvm/tools/clang/tools 目下的 CMakeLists.txt 文件,加入一行 add_clang_subdirectory(插件文件夹名称)
iOS 查漏补缺 - LLVM & Clang_第10张图片
image
  • 在 JHPlugin 目录下新建一个名为 JHPulgin.cpp 的源文件,再新建一个 CMakeLists.txt 的文本文件。
iOS 查漏补缺 - LLVM & Clang_第11张图片
image

CMakeLists.txt 文件中写入如下的内容

add_llvm_library( JHPlugin MODULE BUILDTREE_ONLY
 JHPlugin.cpp
)
  • 使用 cmake 重新生成 Xcode 项目,在 build_xcode 中执行 cmake -G Xcode ../llvm

  • 最后可以在 LLVM 的 Xcode 项目中可以看到 Loadable modules 目录下有自己的 Plugin 目录了。

iOS 查漏补缺 - LLVM & Clang_第12张图片
image

编写插件

1.自定义一个继承于 PluginASTAction 的 Action

// 继承 PluginASTAction
class JHASTAction : public PluginASTAction {
public:
    unique_ptr CreateASTConsumer(CompilerInstance &Compiler, StringRef InFile);
    bool ParseArgs(const CompilerInstance &CI, const std::vector &args);
};

2.注册插件

//注册插件
static FrontendPluginRegistry::Add
    X("JHPlugin", "This is the description of the plugin");

2.自定义一个继承于 ASTConsumer 的 consumer

// 自定义 ASTConsumer
class JHConsumer : public ASTConsumer {

}

ASTConsumer 类型是专门用来解析 AST 语法树的节点的抽象类,通过子类化这个抽象类,我们可以重写 ASTConsumer 类提供的一系列解析节点的方法:

  // HandleTopLevelDecl - Handle the specified top-level declaration.  
  /// This iscalled by the parser to process every top-level Decl*.
  ///
  /// \returns true to continue parsing, or false to abort parsing.
  // 解析一个顶级的声明节点
  virtual bool HandleTopLevelDecl(DeclGroupRef D);
  
  /// HandleTranslationUnit - This method is called when the ASTs for entire
  /// translation unit have been parsed.\
  // 解析完整个文件后被调用
  virtual void HandleTranslationUnit(ASTContext &Ctx) {}

我们在 JHConsumer 里面添加下面两个方法:

  // 解析顶级节点
  bool HandleTopLevelDecl(DeclGroupRef D) {
    cout << "正在解析..." << endl;
    return true;
  }

  // 解析完整个文件后被调用
  void HandleTranslationUnit(ASTContext &Ctx) {
    cout << "文件解析完毕!" << endl;
    matcher.matchAST(Ctx);
  }

然后我们编译一下当前的插件,接着我们用编译好的 clang 和 JHPlugin 来测试一下效果。我们在桌面新建一个 main.m 文件,内容如下:

int test(int a, int b) {
    return a + b;
}

int test2(int a, int b, int c) {
    return a + b + c;
}

int main() {
    test(1, 2);
    test2(1, 2, 3);
    return 0;
}

接着在终端中执行如下的命令:

/Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk -Xclang -load -Xclang /Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/lib/JHPlugin.dylib -Xclang -add-plugin -Xclang JHPlugin -c main.m

这段命令拆分一下:

自己编译的 clang 文件路径  -isysroot iOS的SDK路径 -Xclang -load Xclang 插件的dylib路径 -Xclang -add-plugin -Xclang 插件名称 -c 源文件

最后输出如下:

正在解析...
正在解析...
正在解析...
文件解析完毕!

说明 main.m 中的三个顶级节点以及整个文件都解析完成。

3.最终代码


#include 
#include "clang/AST/AST.h"
#include "clang/AST/DeclObjC.h"
#include "clang/AST/ASTConsumer.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
#include "clang/Frontend/FrontendPluginRegistry.h"

using namespace clang;
using namespace std;
using namespace llvm;
using namespace clang::ast_matchers;


namespace JHPlugin {
    class JHMatchCallback: public MatchFinder::MatchCallback {
    private:
        CompilerInstance &CI;
        //判断是否是自己的文件
        bool isUserSourceCode(const string filename) {
            if (filename.empty()) return false;
            
            // 非Xcode中的源码都认为是用户源码
            if (filename.find("/Applications/Xcode.app/") == 0) return false;
            
            return true;
        }
        
        //判断是否应该用copy修饰。
        bool isShouldUseCopy(const string typeStr) {
            if (typeStr.find("NSString") != string::npos ||
                typeStr.find("NSArray") != string::npos ||
                typeStr.find("NSDictionary") != string::npos/*...*/) {
                return true;
            }
            return false;
        }
        
    public:
        
        JHMatchCallback(CompilerInstance &CI):CI(CI){}
        
        void run(const MatchFinder::MatchResult &Result){
            //通过结果获取到节点。
            const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs("objcPropertyDecl");
            //获取文件名称
            string filename = CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str();
            
            if (propertyDecl && isUserSourceCode(filename)) {//如果节点有值,并且是用户文件
                //拿到属性的类型
                string typeStr = propertyDecl->getType().getAsString();
                //拿到节点的描述信息
                ObjCPropertyDecl::PropertyAttributeKind attrKind = propertyDecl->getPropertyAttributes();
                
                //判断是不是应该用Copy
                if (isShouldUseCopy(typeStr) && !(attrKind & ObjCPropertyDecl::OBJC_PR_copy)) {
                    cout<getBeginLoc(),diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0这个地方推荐用Copy"))< &arg){
            return true;
        }
        
        unique_ptr  CreateASTConsumer(CompilerInstance &CI, StringRef InFile) {
            return unique_ptr  (new JHConsumer(CI));
        }
        
    };
    
}
//注册插件
static FrontendPluginRegistry::Add X("JHPlugin", "This is the description of the plugin");

我们在 ViewController 里面声明如下四个属性:

@interface ViewController ()
@property (nonatomic, strong) NSArray *arr;
@property (nonatomic, strong) NSString *str;
@property (nonatomic, copy) NSArray *arr1;
@property (nonatomic, copy) NSString *str1;
@end

然后运行一下:

/Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk -Xclang -load -Xclang /Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/lib/JHPlugin.dylib -Xclang -add-plugin -Xclang JHPlugin -c ViewController.m

输出如下:

解析完毕了!
NSArray *应该用copy修饰而没用Copy,发出警告!
ViewController.m:12:1: warning: NSArray *这个地方推荐用Copy
@property (nonatomic, strong) NSArray *arr;
^
NSString *应该用copy修饰而没用Copy,发出警告!
ViewController.m:13:1: warning: NSString *这个地方推荐用Copy
@property (nonatomic, strong) NSString *str;
^
2 warnings generated.

可以看到最后由两个应该使用 copy 修饰符的属性因为没有使用 copy 而被监测到并且报了警告。

插件集成到 Xcode

我们上面的方式只能在终端查看插件的执行结果,但是更理想的应该是集成到 Xcode 内部。
我们打开测试项目,在 Build Settings -> Other C Flags 里面添加如下内容:

-Xclang -load Xclang (.dylib)动态库路径 -Xclang -add-plugin -Xclang 插件名
iOS 查漏补缺 - LLVM & Clang_第13张图片
image

此时,我们执行 Command + B 编译一下项目会有如下的报错信息

image

解决方案是添加两个设置,如下所示

image
image
  • CC 对应的是自己编译的 clang 的绝对路径
  • CXX 对应的是自己编译的 clang++ 的绝对路径

接着再修改一个设置,如下所示

iOS 查漏补缺 - LLVM & Clang_第14张图片
image

最后,我们 Command + B 再次编译,注意,这次编译时间会花费得比较久,因为 Xcode 要加载我们自己编译的 clang,等待加载完成后,我们可以看到如下的提示

image

总结

iOS 查漏补缺 - LLVM & Clang_第15张图片
image

参考资料

深入剖析 iOS 编译 Clang / LLVM - 戴铭

高效开发一个 clang plugin

你可能感兴趣的:(iOS 查漏补缺 - LLVM & Clang)