iOS 查漏補缺 - LLVM & Clang

時間 2020-03-23

標籤 ios 補缺 llvm clang 欄目 iOS 简体版

原文原文鏈接

LLVM 是一個自由軟件項目，它是一種編譯器基礎設施，以 C++ 寫成，包含一系列模塊化的編譯器組件和工具鏈，用來開發編譯器前端和後端。它是爲了任意一種編程語言而寫成的程序，利用虛擬技術創造出編譯時期、連接時期、運行時期以及「閒置時期」的最優化。它最先以 C/C++ 爲實現對象，而當前它已支持包括 ActionScript、Ada、D語言、Fortran、GLSL、Haskell、Java字節碼、Objective-C、Swift、Python、Ruby、Crystal、Rust、Scala 以及 C# 等語言。html

-- 維基百科前端

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 等齊名。python

-- 深刻剖析 iOS 編譯 Clang / LLVMios

對於 iOS 開發者來講，Swift 之父 Chris Lattner 的大名應該都會有所耳聞。他和他的團隊所開發的 LLVM 已經成爲 iOS 乃至 macOS 整個生態中相當重要的底層基礎設施。雖然 Lattner 本人已經去 Google 作人工智能了，可是對於 iOS 開發者瞭解並掌握一些關於 LLVM 的基本知識仍是頗有必要的。git

LLVM 初探

LLVM 的官網是 llvm.org/。經過官網咱們能夠看到，LLVM 實際上是一系列的編譯組件的集合。而 Clang (標準讀法是 克朗) 是做爲其中的前端。這裏的前端並非 HTML5 這樣的前端概念。說到這裏，咱們來簡單回顧下傳統編譯器的設計吧。github

傳統編譯器

在 LLVM 誕生以前，使用最普遍的應該是 GCC 編譯器了，固然，GCC 在當下仍然扮演着很重要的角色。objective-c

編譯器前端 Front End

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

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

檢查源代碼是否存在錯誤，而後構建抽象語法樹(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 的官網地址是 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 的源碼 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 - 戴銘

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。