iOS 查漏补缺 - LLVM & Clang

作者: leejunhui | 来源:发表于2020-03-18 00:11 被阅读0次

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 在当下仍然扮演着很重要的角色。

image

编译器前端 Front End

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

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

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

优化器 Optimizer

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

编译器后端 Back End

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

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

LLVM 架构

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

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 后端包括代码优化(优化器)和目标代码生成(后端)两个部分。

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 <stdio.h>

#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 文件的内容:

image

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

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

#include <stdio.h>

#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

结果如下

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 <stdio.h>

#define C 30
typedef int JH_INT_64;
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        JH_INT_64 a '       Loc=<main.m:9:1>
typedef 'typedef'    [StartOfLine]  Loc=<main.m:12:1>
int 'int'    [LeadingSpace] Loc=<main.m:12:9>
identifier 'JH_INT_64'   [LeadingSpace] Loc=<main.m:12:13>
semi ';'        Loc=<main.m:12:22>
int 'int'    [StartOfLine]  Loc=<main.m:13:1>
identifier 'main'    [LeadingSpace] Loc=<main.m:13:5>
l_paren '('     Loc=<main.m:13:9>
int 'int'       Loc=<main.m:13:10>
identifier 'argc'    [LeadingSpace] Loc=<main.m:13:14>
comma ','       Loc=<main.m:13:18>
const 'const'    [LeadingSpace] Loc=<main.m:13:20>
char 'char'  [LeadingSpace] Loc=<main.m:13:26>
star '*'     [LeadingSpace] Loc=<main.m:13:31>
identifier 'argv'    [LeadingSpace] Loc=<main.m:13:33>
l_square '['        Loc=<main.m:13:37>
r_square ']'        Loc=<main.m:13:38>
r_paren ')'     Loc=<main.m:13:39>
l_brace '{'  [LeadingSpace] Loc=<main.m:13:41>
at '@'   [StartOfLine] [LeadingSpace]   Loc=<main.m:14:5>
identifier 'autoreleasepool'        Loc=<main.m:14:6>
l_brace '{'  [LeadingSpace] Loc=<main.m:14:22>
identifier 'JH_INT_64'   [StartOfLine] [LeadingSpace]   Loc=<main.m:15:9>
identifier 'a'   [LeadingSpace] Loc=<main.m:15:19>
equal '='    [LeadingSpace] Loc=<main.m:15:21>
numeric_constant '10'    [LeadingSpace] Loc=<main.m:15:23>
semi ';'        Loc=<main.m:15:25>
identifier 'JH_INT_64'   [StartOfLine] [LeadingSpace]   Loc=<main.m:16:9>
identifier 'b'   [LeadingSpace] Loc=<main.m:16:19>
equal '='    [LeadingSpace] Loc=<main.m:16:21>
numeric_constant '20'    [LeadingSpace] Loc=<main.m:16:23>
semi ';'        Loc=<main.m:16:25>
identifier 'printf'  [StartOfLine] [LeadingSpace]   Loc=<main.m:17:9>
l_paren '('     Loc=<main.m:17:15>
string_literal '"%d"'       Loc=<main.m:17:16>
comma ','       Loc=<main.m:17:20>
identifier 'a'   [LeadingSpace] Loc=<main.m:17:22>
plus '+'     [LeadingSpace] Loc=<main.m:17:24>
identifier 'b'   [LeadingSpace] Loc=<main.m:17:26>
plus '+'     [LeadingSpace] Loc=<main.m:17:28>
numeric_constant '30'    [LeadingSpace] Loc=<main.m:17:30 <Spelling=main.m:11:11>>
r_paren ')'     Loc=<main.m:17:31>
semi ';'        Loc=<main.m:17:32>
r_brace '}'  [StartOfLine] [LeadingSpace]   Loc=<main.m:18:5>
return 'return'  [StartOfLine] [LeadingSpace]   Loc=<main.m:19:5>
numeric_constant '0'     [LeadingSpace] Loc=<main.m:19:12>
semi ';'        Loc=<main.m:19:13>
r_brace '}'  [StartOfLine]  Loc=<main.m:20:1>
eof ''      Loc=<main.m:20:2>

可以看到，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 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0x7fa0aa017ca0 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128'
| `-BuiltinType 0x7fa0aa0179a0 '__int128'
|-TypedefDecl 0x7fa0aa017d08 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x7fa0aa0179c0 'unsigned __int128'
|-TypedefDecl 0x7fa0aa017da0 <<invalid sloc>> <invalid sloc> implicit SEL 'SEL *'
| `-PointerType 0x7fa0aa017d60 'SEL *'
|   `-BuiltinType 0x7fa0aa017c00 'SEL'
|-TypedefDecl 0x7fa0aa017e78 <<invalid sloc>> <invalid sloc> implicit id 'id'
| `-ObjCObjectPointerType 0x7fa0aa017e20 'id'
|   `-ObjCObjectType 0x7fa0aa017df0 'id'
|-TypedefDecl 0x7fa0aa017f58 <<invalid sloc>> <invalid sloc> implicit Class 'Class'
| `-ObjCObjectPointerType 0x7fa0aa017f00 'Class'
|   `-ObjCObjectType 0x7fa0aa017ed0 'Class'
|-ObjCInterfaceDecl 0x7fa0aa017fa8 <<invalid sloc>> <invalid sloc> implicit Protocol
|-TypedefDecl 0x7fa0aa0182e8 <<invalid sloc>> <invalid sloc> implicit __NSConstantString 'struct __NSConstantString_tag'
| `-RecordType 0x7fa0aa018100 'struct __NSConstantString_tag'
|   `-Record 0x7fa0aa018070 '__NSConstantString_tag'
|-TypedefDecl 0x7fa0aa018380 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x7fa0aa018340 'char *'
|   `-BuiltinType 0x7fa0aa0174a0 'char'
|-TypedefDecl 0x7fa0aa054e68 <<invalid sloc>> <invalid sloc> 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 <main.m:9:1> col:1 implicit Darwin.C.stdio
|-TypedefDecl 0x7fa0aa0556c0 <line:12:1, col:13> col:13 referenced JH_INT_64 'int'
| `-BuiltinType 0x7fa0aa017500 'int'
|-FunctionDecl 0x7fa0aa055980 <line:13:1, line:20:1> line:13:5 main 'int (int, const char **)'
| |-ParmVarDecl 0x7fa0aa055728 <col:10, col:14> col:14 argc 'int'
| |-ParmVarDecl 0x7fa0aa055840 <col:20, col:38> col:33 argv 'const char **':'const char **'
| `-CompoundStmt 0x7fa0aa1dc880 <col:41, line:20:1>
|   |-ObjCAutoreleasePoolStmt 0x7fa0aa1dc838 <line:14:5, line:18:5>
|   | `-CompoundStmt 0x7fa0aa1dc810 <line:14:22, line:18:5>
|   |   |-DeclStmt 0x7fa0aa055b60 <line:15:9, col:25>
|   |   | `-VarDecl 0x7fa0aa055ae0 <col:9, col:23> col:19 used a 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa055b40 <col:23> 'int' 10
|   |   |-DeclStmt 0x7fa0aa1dc5d0 <line:16:9, col:25>
|   |   | `-VarDecl 0x7fa0aa055b88 <col:9, col:23> col:19 used b 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa1dc200 <col:23> 'int' 20
|   |   `-CallExpr 0x7fa0aa1dc7b0 <line:17:9, col:31> 'int'
|   |     |-ImplicitCastExpr 0x7fa0aa1dc798 <col:9> 'int (*)(const char *, ...)' <FunctionToPointerDecay>
|   |     | `-DeclRefExpr 0x7fa0aa1dc5e8 <col:9> 'int (const char *, ...)' Function 0x7fa0aa1dc228 'printf' 'int (const char *, ...)'
|   |     |-ImplicitCastExpr 0x7fa0aa1dc7f8 <col:16> 'const char *' <NoOp>
|   |     | `-ImplicitCastExpr 0x7fa0aa1dc7e0 <col:16> 'char *' <ArrayToPointerDecay>
|   |     |   `-StringLiteral 0x7fa0aa1dc648 <col:16> 'char [3]' lvalue "%d"
|   |     `-BinaryOperator 0x7fa0aa1dc748 <col:22, line:11:11> 'int' '+'
|   |       |-BinaryOperator 0x7fa0aa1dc708 <line:17:22, col:26> 'int' '+'
|   |       | |-ImplicitCastExpr 0x7fa0aa1dc6d8 <col:22> 'JH_INT_64':'int' <LValueToRValue>
|   |       | | `-DeclRefExpr 0x7fa0aa1dc668 <col:22> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055ae0 'a' 'JH_INT_64':'int'
|   |       | `-ImplicitCastExpr 0x7fa0aa1dc6f0 <col:26> 'JH_INT_64':'int' <LValueToRValue>
|   |       |   `-DeclRefExpr 0x7fa0aa1dc6a0 <col:26> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055b88 'b' 'JH_INT_64':'int'
|   |       `-IntegerLiteral 0x7fa0aa1dc728 <line:11:11> 'int' 30
|   `-ReturnStmt 0x7fa0aa1dc870 <line:19:5, col:12>
|     `-IntegerLiteral 0x7fa0aa1dc850 <col:12> 'int' 0
`-<undeserialized declarations>

在执行语法分析命令的时候，如果有引入 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:1, line:20:1> line:13:5 main 'int (int, const char **)'

开头的 FunctionDecl 表示是一个函数声明节点。后面跟了一个内存地址，就其实是栈空间内的函数的地址。尖括号里面的内容表示是 main 函数的起始范围，从第 13 行的第 1 个字符开始，到第 20 行的第 1 个字符结束。然后后面的 line:13:5 表示从第 13 行的第 5 个字符开始是函数的参数声明区域。

| |-ParmVarDecl 0x7fa0aa055728 <col:10, col:14> col:14 argc 'int'
| |-ParmVarDecl 0x7fa0aa055840 <col:20, col:38> col:33 argv 'const char **':'const char **'

这两个节点类型为 ParmVarDecl，表示的是参数节点，其中第一个参数 argc 是 int 类型，第二个参数 argv 是 const char** 类型。

|   `-CallExpr 0x7fa0aa1dc7b0 <line:17:9, col:31> 'int'

CallExpr 表示的是调用某个函数。后面的 int 表示调用函数的返回值。这里其实就是源码中 printf 函数的位置。

|   |   |-DeclStmt 0x7fa0aa055b60 <line:15:9, col:25>
|   |   | `-VarDecl 0x7fa0aa055ae0 <col:9, col:23> col:19 used a 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa055b40 <col:23> 'int' 10
|   |   |-DeclStmt 0x7fa0aa1dc5d0 <line:16:9, col:25>
|   |   | `-VarDecl 0x7fa0aa055b88 <col:9, col:23> col:19 used b 'JH_INT_64':'int' cinit
|   |   |   `-IntegerLiteral 0x7fa0aa1dc200 <col:23> 'int' 20

DeclStmt 表示的是声明语句节点，这里很容易就能看出声明了两个 int 类型的变量，一个值为 10，一个值为 20。

|   |     |-ImplicitCastExpr 0x7fa0aa1dc798 <col:9> 'int (*)(const char *, ...)' <FunctionToPointerDecay>
|   |     | `-DeclRefExpr 0x7fa0aa1dc5e8 <col:9> 'int (const char *, ...)' Function 0x7fa0aa1dc228 'printf' 'int (const char *, ...)'
|   |     |-ImplicitCastExpr 0x7fa0aa1dc7f8 <col:16> 'const char *' <NoOp>
|   |     | `-ImplicitCastExpr 0x7fa0aa1dc7e0 <col:16> 'char *' <ArrayToPointerDecay>
|   |     |   `-StringLiteral 0x7fa0aa1dc648 <col:16> 'char [3]' lvalue "%d"

ImplicitCastExpr 表示隐式转换表达式节点，说明 printf 函数其实前面还有隐式转换的操作： int (*)(const char *, ...)。
最后一行显然就是 printf 函数的开头位置的 %d，表示接收一个 int 类型的值。

|   |     `-BinaryOperator 0x7fa0aa1dc748 <col:22, line:11:11> 'int' '+'
|   |       |-BinaryOperator 0x7fa0aa1dc708 <line:17:22, col:26> 'int' '+'
|   |       | |-ImplicitCastExpr 0x7fa0aa1dc6d8 <col:22> 'JH_INT_64':'int' <LValueToRValue>
|   |       | | `-DeclRefExpr 0x7fa0aa1dc668 <col:22> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055ae0 'a' 'JH_INT_64':'int'
|   |       | `-ImplicitCastExpr 0x7fa0aa1dc6f0 <col:26> 'JH_INT_64':'int' <LValueToRValue>
|   |       |   `-DeclRefExpr 0x7fa0aa1dc6a0 <col:26> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055b88 'b' 'JH_INT_64':'int'
|   |       `-IntegerLiteral 0x7fa0aa1dc728 <line:11:11> 'int' 30

BinaryOperator 表示的是二元运算符。这里阅读的方式应该是先看叶子节点，所以翻译过来就是 (a + b) + 30 的结果作为 printf 函数的入参。

|   `-ReturnStmt 0x7fa0aa1dc870 <line:19:5, col:12>
|     `-IntegerLiteral 0x7fa0aa1dc850 <col:12> '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 <stdio.h>

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 模式下对应的优化级别:

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
  
  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, 我们看下它是如何执行的：

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(插件文件夹名称)

image

在 JHPlugin 目录下新建一个名为 JHPulgin.cpp 的源文件，再新建一个 CMakeLists.txt 的文本文件。

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 目录了。

image

编写插件

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

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

2.注册插件

//注册插件
static FrontendPluginRegistry::Add<JHPlugin::JHASTAction>
    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 <iostream>
#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>("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<<typeStr<<"应该用copy修饰而没用Copy，发出警告！"<<endl;
                    //诊断引擎
                    DiagnosticsEngine &diag = CI.getDiagnostics();
                    //Report 报告
                    diag.Report(propertyDecl->getBeginLoc(),diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0这个地方推荐用Copy"))<<typeStr;
                }
            }
        }
    };
    
    
    
    
    
    
    
    //自定义的JHConsumer
    class JHConsumer: public ASTConsumer {
    private:
        MatchFinder matcher;
        JHMatchCallback callback;
    public:
        JHConsumer(CompilerInstance &CI):callback(CI){
            
            //添加一个MatchFinder去匹objcPropertyDecl节点
            //回调在JHMatchCallback的run方法里面。
            matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"),&callback);
        }

        // 在整个文件都解析完后被调用
        void HandleTranslationUnit(ASTContext &context) {
            cout<<"解析完毕了！"<<endl;
            matcher.matchAST(context);
        }
    };
   
    //继承PluginASTAction实现我们自定义的 Action
    class JHASTAction: public PluginASTAction {
    public:
        bool ParseArgs(const CompilerInstance &CI,const vector<string> &arg){
            return true;
        }
        
        unique_ptr <ASTConsumer> CreateASTConsumer(CompilerInstance &CI, StringRef InFile) {
            return unique_ptr <JHConsumer> (new JHConsumer(CI));
        }
        
    };
    
}
//注册插件
static FrontendPluginRegistry::Add<JHPlugin::JHASTAction> 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 插件名

image

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

image

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

image

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

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

image

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

image

总结

image

参考资料

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

高效开发一个 clang plugin

iOS 查漏补缺 - LLVM & Clang

LLVM 初探

传统编译器

编译器前端 Front End

优化器 Optimizer

编译器后端 Back End

LLVM 架构

Clang

iOS 中的编译过程

预处理阶段

编译阶段

词法分析

语法分析

生成中间代码 IR

生成汇编代码

生成目标文件

生成可执行文件

编译 LLVM 工程

LLVM 下载

LLVM 编译

安装 cmake

通过 Xcode 编译 LLVM

Clang 插件初探

创建插件

编写插件

插件集成到 Xcode

总结

参考资料

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

初见