iOS 查漏補缺 - LLVM & Clang

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

編譯器前端 Front End

編譯器前端的任務是解析源代碼，具體工作內容包括下列三個流程

• 詞法分析
• 語法分析
• 語義分析

檢查源代碼是否存在錯誤，然後構建抽象語法樹(Abstract Syntax Tree, AST)。
LLVM的前端還會生成中間代碼(intermediate representation, IR)。

優化器 Optimizer

優化器負責進行各種優化。改善代碼的運行時間，例如消除冗餘計算等。

編譯器後端 Back End

將代碼映射到目標指令集。生成機器語言，並且進行機器相關的代碼優化。
有些資料也會把編譯器後端成爲 代碼生成器 Code Generator。

從上面的內容可以看到，傳統的編譯器架構前端和後端之間耦合度太高，如果要支持一門新的編程語言，或者一個新的目標平臺，工作量會非常大。

LLVM 架構

LLVM 之所以能夠成爲編譯器中的中流砥柱，最重要的就是使用了通用的代碼表現形式，也就是 IR。有了 IR，LLVM 就可以爲任何編程語言獨立編寫前端，並且可以爲任意硬件架構獨立編寫後端。

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 中的編譯過程

在探索編譯過程之前，我們先通過一個命令來打印出源碼的編譯階段

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

可以看到，宏已經被替換了，並且 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

結果如下

可以看到，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 模式下對應的優化級別:

優化級別從低到高分爲:

• 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
    

  • 編譯，選擇 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, 我們看下它是如何執行的：

具體是在動態庫裝載進來後，可以拿到我們自定義的 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 目下新建插件的文件夾

• 修改 /llvm/tools/clang/tools 目下的 CMakeLists.txt 文件，加入一行 add_clang_subdirectory(插件文件夾名稱)

• 在 JHPlugin 目錄下新建一個名爲 JHPulgin.cpp 的源文件，再新建一個 CMakeLists.txt 的文本文件。

CMakeLists.txt 文件中寫入如下的內容

add_llvm_library( JHPlugin MODULE BUILDTREE_ONLY
 JHPlugin.cpp
)

• 使用 cmake 重新生成 Xcode 項目，在 build_xcode 中執行 cmake -G Xcode ../llvm

• 最後可以在 LLVM 的 Xcode 項目中可以看到 Loadable modules 目錄下有自己的 Plugin 目錄了。

編寫插件

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 插件名

此時，我們執行 Command + B 編譯一下項目會有如下的報錯信息

解決方案是添加兩個設置，如下所示

• CC 對應的是自己編譯的 clang 的絕對路徑
• CXX 對應的是自己編譯的 clang++ 的絕對路徑

接着再修改一個設置，如下所示

最後，我們 Command + B 再次編譯，注意，這次編譯時間會花費得比較久，因爲 Xcode 要加載我們自己編譯的 clang，等待加載完成後，我們可以看到如下的提示

總結

參考資料

深入剖析 iOS 編譯 Clang / LLVM - 戴銘

高效開發一個 clang plugin