深入剖析 iOS 編譯 Clang / LLVM

發表於2017-01-08

前言

iOS 開發中 Objective-C 和 Swift 都用的是 Clang / LLVM 來編譯的。LLVM是一個模組化和可重用的編譯器和工具鏈技術的集合，Clang 是 LLVM 的子專案，是 C，C++ 和 Objective-C 編譯器，目的是提供驚人的快速編譯，比 GCC 快3倍，其中的 clang static analyzer 主要是進行語法分析，語義分析和生成中間程式碼，當然這個過程會對程式碼進行檢查，出錯的和需要警告的會標註出來。LLVM 核心庫提供一個優化器，對流行的 CPU 做程式碼生成支援。lld 是 Clang / LLVM 的內建連結器，clang 必須呼叫連結器來產生可執行檔案。

LLVM 比較有特色的一點是它能提供一種程式碼編寫良好的中間表示 IR，這意味著它可以作為多種語言的後端，這樣就能夠提供語言無關的優化同時還能夠方便的針對多種 CPU 的程式碼生成。

編譯流程

在列出完整步驟之前可以先看個簡單例子。看看是如何完成一次編譯的。

#import

#define DEFINEEight 8

int main(){

@autoreleasepool {

int eight = DEFINEEight;

int six = 6;

NSString* site = [[NSString alloc] initWithUTF8String:"starming"];

int rank = eight + six;

NSLog(@"%@ rank %d", site, rank);

}

return 0;

}

在命令列編譯

1 2	xcrun -sdk iphoneos clang -arch armv7 -F Foundation -fobjc-arc -c main.m -o main.o xcrun -sdk iphoneos clang main.o -arch armv7 -fobjc-arc -framework Foundation -o main

在手機上就能夠直接執行main了。這樣還沒發看清clang的全部過程，可以通過-E檢視clang在預處理處理這步做了什麼。

1	clang -E main.m

執行完後可以看到檔案

# 1 "/System/Library/Frameworks/Foundation.framework/Headers/FoundationLegacySwiftCompatibility.h" 1 3

# 185 "/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h" 2 3

# 2 "main.m" 2

int main(){

@autoreleasepool {

int eight = 8;

int six = 6;

NSString* site = [[NSString alloc] initWithUTF8String:"starming"];

int rank = eight + six;

NSLog(@"%@ rank %d", site, rank);

}

return 0;

}

這個過程的處理包括巨集的替換，標頭檔案的匯入，以及類似#if的處理。預處理完成後就會進行詞法分析，這裡會把程式碼切成一個個 Token，比如大小括號，等於號還有字串等。

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

然後是語法分析，驗證語法是否正確，然後將所有節點組成抽象語法樹 AST 。

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

完成這些步驟後就可以開始IR中間程式碼的生成了，CodeGen 會負責將語法樹自頂向下遍歷逐步翻譯成 LLVM IR，IR 是編譯過程的前端的輸出後端的輸入。

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

這裡 LLVM 會去做些優化工作，在 Xcode 的編譯設定裡也可以設定優化級別-01，-03，-0s，還可以寫些自己的 Pass。

Pass 是 LLVM 優化工作的一個節點，一個節點做些事，一起加起來就構成了 LLVM 完整的優化和轉化。

如果開啟了 bitcode 蘋果會做進一步的優化，有新的後端架構還是可以用這份優化過的 bitcode 去生成。

1	clang -emit-llvm -c main.m -o main.bc

生成彙編

1	clang -S -fobjc-arc main.m -o main.s

生成目標檔案

1	clang -fmodules -c main.m -o main.o

生成可執行檔案，這樣就能夠執行看到輸出結果

clang main.o -o main

執行

./main

輸出

starming rank 14

下面是完整步驟：

編譯資訊寫入輔助檔案，建立檔案架構 .app 檔案
處理檔案打包資訊
執行 CocoaPod 編譯前指令碼，checkPods Manifest.lock
編譯.m檔案，使用 CompileC 和 clang 命令
連結需要的 Framework
編譯 xib
拷貝 xib ，資原始檔
編譯 ImageAssets
處理 info.plist
執行 CocoaPod 指令碼
拷貝標準庫
建立 .app 檔案和簽名

Clang 編譯 .m 檔案

在 Xcode 編譯過後，可以通過 Show the report navigator 裡對應 target 的 build 中檢視每個 .m 檔案的 clang 編譯資訊。

具體拿編譯 AFSecurityPolicy.m 的資訊來看看。首先對任務進行描述。

1	CompileC DerivedData path/AFSecurityPolicy.o AFNetworking/AFNetworking/AFSecurityPolicy.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler

接下來對會更新工作路徑，同時設定 PATH

cd /Users/didi/Documents/Demo/GitHub/GCDFetchFeed/GCDFetchFeed/Pods

export LANG=en_US.US-ASCII

export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"

接下來就是實際的編譯命令

1	clang -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-arc... -Wno-missing-field-initializers ... -DDEBUG=1 ... -isysroot iPhoneSimulator10.1.sdk -fasm-blocks ... -I -F -c AFSecurityPolicy.m -o AFSecurityPolicy.o

clang 命令引數

-x 編譯語言比如objective-c

-arch 編譯的架構，比如arm7

-f 以-f開頭的。

-W 以-W開頭的，可以通過這些定製編譯警告

-D 以-D開頭的，指的是預編譯巨集，通過這些巨集可以實現條件編譯

-iPhoneSimulator10.1.sdk 編譯採用的iOS SDK版本

-I 把編譯資訊寫入指定的輔助檔案

-F 需要的Framework

-c 識別符號指明需要執行前處理器，語法分析，型別檢查，LLVM生成優化以及彙編程式碼生成.o檔案

-o 編譯結果

構建 Target

編譯工程中的第三方依賴庫後會構建我們程式的 target，會按順序輸出如下的資訊：

Create product structure

Process product packaging

Run custom shell script 'Check Pods Manifest.lock'

Compile ... 各個專案中的.m檔案

Link /Users/... 路徑

Copy ... 靜態檔案

Compile asset catalogs

Compile Storyboard file ...

Process info.plist

Link Storyboards

Run custom shell script 'Embed Pods Frameworks'

Run custom shell script 'Copy Pods Resources'

...

Touch GCDFetchFeed.app

Sign GCDFetchFeed.app

從這些資訊可以看出在這些步驟中會分別呼叫不同的命令列工具來執行。

Target 在 Build 過程的控制

在 Xcode 的 Project editor 中的 Build Setting，Build Phases 和 Build Rules 能夠控制編譯的過程。

Build Phases

構建可執行檔案的規則。指定 target 的依賴專案，在 target build 之前需要先 build 的依賴。在 Compile Source 中指定所有必須編譯的檔案，這些檔案會根據 Build Setting 和 Build Rules 裡的設定來處理。

在 Link Binary With Libraries 裡會列出所有的靜態庫和動態庫，它們會和編譯生成的目標檔案進行連結。

build phase 還會把靜態資源拷貝到 bundle 裡。

可以通過在 build phases 裡新增自定義指令碼來做些事情，比如像 CocoaPods 所做的那樣。

Build Rules

指定不同檔案型別如何編譯。每條 build rule 指定了該型別如何處理以及輸出在哪。可以增加一條新規則對特定檔案型別新增處理方法。

Build Settings

在 build 的過程中各個階段的選項的設定。

pbxproj工程檔案

build 過程控制的這些設定都會被儲存在工程檔案 .pbxproj 裡。在這個檔案中可以找 rootObject 的 ID 值

1	rootObject = 3EE311301C4E1F0800103FA3 /* Project object */;

然後根據這個 ID 找到 main 工程的定義。

/* Begin PBXProject section */

3EE311301C4E1F0800103FA3 /* Project object */ = {

isa = PBXProject;

...

/* End PBXProject section */

在 targets 裡會指向各個 taget 的定義

targets = (

3EE311371C4E1F0800103FA3 /* GCDFetchFeed */,

3EE311501C4E1F0800103FA3 /* GCDFetchFeedTests */,

3EE3115B1C4E1F0800103FA3 /* GCDFetchFeedUITests */,

);

順著這些 ID 就能夠找到更詳細的定義地方。比如我們通過 GCDFetchFeed 這個 target 的 ID 找到定義如下：

3EE311371C4E1F0800103FA3 /* GCDFetchFeed */ = {

isa = PBXNativeTarget;

buildConfigurationList = 3EE311651C4E1F0800103FA3 /* configuration list for PBXNativeTarget "GCDFetchFeed"

buildPhases = (

9527AA01F4AAE11E18397E0C /* Check Pods st.lock */,

3EE311341C4E1F0800103FA3 /* Sources */,

3EE311351C4E1F0800103FA3 /* Frameworks */,

3EE311361C4E1F0800103FA3 /* Resources */,

C3DDA7C46C0308459A18B7D9 /* Embed Pods Frameworks

DD33A716222617FAB49F1472 /* Copy Pods Resources

);

buildRules = (

);

dependencies = (

);

name = GCDFetchFeed;

productName = GCDFetchFeed;

productReference = 3EE311381C4E1F0800103FA3 /* chFeed.app */;

productType = "com.apple.product-type.application";

};

這個裡面又有更多的 ID 可以得到更多的定義，其中 buildConfigurationList 指向了可用的配置項，包含 Debug 和 Release。可以看到還有 buildPhases，buildRules 和 dependencies 都能夠通過這裡索引找到更詳細的定義。

接下來看看 Clang 所做的事情。

Clang Static Analyzer靜態程式碼分析

可以在 llvm/clang/ Source Tree – Woboq Code Browser 上檢視 Clang 的程式碼。

clang 靜態分析是通過建立分析引擎和 checkers 所組成的架構，這部分功能可以通過 clang —analyze 命令方式呼叫。clang static analyzer 分為 analyzer core 分析引擎和 checkers 兩部分，所有 checker 都是基於底層分析引擎之上，通過分析引擎提供的功能能夠編寫新的 checker。

可以通過 clang –analyze -Xclang -analyzer-checker-help 來列出當前 clang 版本下所有 checker。如果想編寫自己的 checker，可以在 clang 專案的 StaticAnalyzer/Checkers 目錄下找到例項參考。這種方式能夠方便使用者擴充套件對程式碼檢查規則或者對 bug 型別進行擴充套件，但是這種架構也有不足，每執行完一條語句後，分析引擎會遍歷所有 checker 中的回撥函式，所以 checker 越多，速度越慢。通過 clang -cc1 -analyzer-checker-help 可以列出能呼叫的 checker，下面是常用 checker

debug.ConfigDumper Dump config table

debug.DumpCFG Display Control-Flow Graphs

debug.DumpCallGraph Display Call Graph

debug.DumpCalls Print calls as they are traversed by the engine

debug.DumpDominators Print the dominance tree for a given CFG

debug.DumpLiveVars Print results of live variable analysis

debug.DumpTraversal Print branch conditions as they are traversed by the engine

debug.ExprInspection Check the analyzer's understanding of expressions

debug.Stats Emit warnings with analyzer statistics

debug.TaintTest Mark tainted symbols as such.

debug.ViewCFG View Control-Flow Graphs using GraphViz

debug.ViewCallGraph View Call Graph using GraphViz

debug.ViewExplodedGraph View Exploded Graphs using GraphViz

這些 checker 裡最常用的是 DumpCFG，DumpCallGraph，DumpLiveVars 和 DumpViewExplodedGraph。

clang static analyzer 引擎大致分為 CFG，MemRegion，SValBuilder，ConstraintManager 和 ExplodedGraph 幾個模組。clang static analyzer 本質上就是 path-sensitive analysis，要很好的理解 clang static analyzer 引擎就需要對 Data Flow Analysis 有所瞭解，包括迭代資料流分析，path-sensitive，path-insensitive ，flow-sensitive等。

編譯的概念（詞法->語法->語義->IR->優化->CodeGen）在 clang static analyzer 裡到處可見，例如 Relaxed Live Variables Analysis 可以減少分析中的記憶體消耗，使用 mark-sweep 實現 Dead Symbols 的刪除。

clang static analyzer 提供了很多輔助方法，比如 SVal.dump()，MemRegion.getString 以及 Stmt 和 Dcel 提供的 dump 方法。Clang 抽象語法樹 Clang AST 常見的 API 有 Stmt，Decl，Expr 和 QualType。在編寫 checker 時會遇到 AST 的層級檢查，這時有個很好的介面 StmtVisitor，這個介面類似 RecursiveASTVisitor。

整個 clang static analyzer 的入口是 AnalysisConsumer，接著會調 HandleTranslationUnit() 方法進行 AST 層級進行分析或者進行 path-sensitive 分析。預設會按照 inline 的 path-sensitive 分析，構建 CallGraph，從頂層 caller 按照呼叫的關係來分析，具體是使用的 WorkList 演算法，從 EntryBlock 開始一步步的模擬，這個過程叫做 intra-procedural analysis（IPA）。這個模擬過程還需要對記憶體進行模擬，clang static analyzer 的記憶體模型是基於《A Memory Model for Static Analysis of C Programs》這篇論文而來，pdf地址：http://lcs.ios.ac.cn/~xuzb/canalyze/memmodel.pdf 在clang裡的具體實現程式碼可以檢視這兩個檔案 MemRegion.h和 RegionStore.cpp 。

下面舉個簡單例子看看 clang static analyzer 是如何對原始碼進行模擬的。

int main()

{

int a;

int b = 10;

a = b;

return a;

}

對應的 AST 以及 CFG

#----------------AST-------------------
# clang -cc1 -ast-dump
TranslationUnitDecl 0xc75b450 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0xc75b740 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'char *'
`-FunctionDecl 0xc75b7b0 <test.cpp:1:1, line:7:1> line:1:5 main 'int (void)'
  `-CompoundStmt 0xc75b978 <line:2:1, line:7:1>
    |-DeclStmt 0xc75b870 <line:3:2, col:7>
    | `-VarDecl 0xc75b840 <col:2, col:6> col:6 used a 'int'
    |-DeclStmt 0xc75b8d8 <line:4:2, col:12>
    | `-VarDecl 0xc75b890 <col:2, col:10> col:6 used b 'int' cinit
    |   `-IntegerLiteral 0xc75b8c0 <col:10> 'int' 10

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< a = b <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    |-BinaryOperator 0xc75b928 <line:5:2, col:6> 'int' lvalue '='
    | |-DeclRefExpr 0xc75b8e8 <col:2> 'int' lvalue Var 0xc75b840 'a' 'int'
    | `-ImplicitCastExpr 0xc75b918 <col:6> 'int' <LValueToRValue>
    |   `-DeclRefExpr 0xc75b900 <col:6> 'int' lvalue Var 0xc75b890 'b' 'int'
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

`-ReturnStmt 0xc75b968 <line:6:2, col:9>
      `-ImplicitCastExpr 0xc75b958 <col:9> 'int' <LValueToRValue>
        `-DeclRefExpr 0xc75b940 <col:9> 'int' lvalue Var 0xc75b840 'a' 'int'
#----------------CFG-------------------
# clang -cc1 -analyze -analyzer-checker=debug.DumpCFG
int main()
 [B2 (ENTRY)]
   Succs (1): B1

[B1]
   1: int a;
   2: 10
   3: int b = 10;
   4: b
   5: [B1.4] (ImplicitCastExpr, LValueToRValue, int)
   6: a
   7: [B1.6] = [B1.5]
   8: a
   9: [B1.8] (ImplicitCastExpr, LValueToRValue, int)
  10: return [B1.9];
   Preds (1): B2
   Succs (1): B0

[B0 (EXIT)]
   Preds (1): B1

#----------------AST-------------------

# clang -cc1 -ast-dump

TranslationUnitDecl 0xc75b450 <<invalid sloc>> <invalid sloc>

|-TypedefDecl 0xc75b740 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'char *'

`-FunctionDecl 0xc75b7b0 <test.cpp:1:1, line:7:1> line:1:5 main 'int (void)'

`-CompoundStmt 0xc75b978 <line:2:1, line:7:1>

|-DeclStmt 0xc75b870 <line:3:2, col:7>

| `-VarDecl 0xc75b840 <col:2, col:6> col:6 used a 'int'

|-DeclStmt 0xc75b8d8 <line:4:2, col:12>

| `-VarDecl 0xc75b890 <col:2, col:10> col:6 used b 'int' cinit

| `-IntegerLiteral 0xc75b8c0 <col:10> 'int' 10

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< a = b <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

|-BinaryOperator 0xc75b928 <line:5:2, col:6> 'int' lvalue '='

| |-DeclRefExpr 0xc75b8e8 <col:2> 'int' lvalue Var 0xc75b840 'a' 'int'

| `-ImplicitCastExpr 0xc75b918 <col:6> 'int' <LValueToRValue>

| `-DeclRefExpr 0xc75b900 <col:6> 'int' lvalue Var 0xc75b890 'b' 'int'

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

`-ReturnStmt 0xc75b968 <line:6:2, col:9>

`-ImplicitCastExpr 0xc75b958 <col:9> 'int' <LValueToRValue>

`-DeclRefExpr 0xc75b940 <col:9> 'int' lvalue Var 0xc75b840 'a' 'int'

#----------------CFG-------------------

# clang -cc1 -analyze -analyzer-checker=debug.DumpCFG

int main()

[B2 (ENTRY)]

Succs (1): B1

[B1]

1: int a;

2: 10

3: int b = 10;

4: b

5: [B1.4] (ImplicitCastExpr, LValueToRValue, int)

6: a

7: [B1.6] = [B1.5]

8: a

9: [B1.8] (ImplicitCastExpr, LValueToRValue, int)

10: return [B1.9];

Preds (1): B2

Succs (1): B0

[B0 (EXIT)]

Preds (1): B1

CFG 將程式拆得更細，能夠將執行的過程表現的更直觀些，為了避免路徑爆炸，函式 inline 的條件會設定的比較嚴格，函式 CFG 塊多時不會進行 inline 分析，模擬棧深度超過一定值不會進行 inline 分析，這個預設是5。

Clang Attributes

以 attribute(xx) 的語法格式出現，是 Clang 提供的一些能夠讓開發者在編譯過程中參與一些原始碼控制的方法。下面列一些會用到的用法：

attribute((format(NSString, F, A))) 格式化字串

可以檢視 NSLog 的用法

FOUNDATION_EXPORT void NSLog(NSString *format, ...) NS_FORMAT_FUNCTION(1,2) NS_NO_TAIL_CALL;

// Marks APIs which format strings by taking a format string and optional varargs as arguments

#if !defined(NS_FORMAT_FUNCTION)

#if (__GNUC__*10+__GNUC_MINOR__ >= 42) && (TARGET_OS_MAC || TARGET_OS_EMBEDDED)

#define NS_FORMAT_FUNCTION(F,A) __attribute__((format(__NSString__, F, A)))

#else

#define NS_FORMAT_FUNCTION(F,A)

#endif

attribute((deprecated(s))) 版本棄用提示

在編譯過程中能夠提示開發者該方法或者屬性已經被棄用

1 2	- (void)preMethod:( NSString *)string __attribute__((deprecated("preMethod已經被棄用，請使用newMethod"))); - (void)deprecatedMethod DEPRECATED_ATTRIBUTE; //也可以直接使用DEPRECATED_ATTRIBUTE這個系統定義的巨集

attribute((availability(os,introduced=m,deprecated=n, obsoleted=o,message=”” VA_ARGS))) 指明使用版本範圍

os 指系統的版本，m 指明引入的版本，n 指明過時的版本，o 指完全不用的版本，message 可以寫入些描述資訊。

1	- (void)method __attribute__((availability(ios,introduced=3_0,deprecated=6_0,obsoleted=7_0,message="iOS3到iOS7版本可用，iOS7不能用")));

attribute((unavailable(…))) 方法不可用提示

這個會在編譯過程中告知方法不可用，如果使用了還會讓編譯失敗。

attribute((unused))

沒有被使用也不報警告

attribute((warn_unused_result))

不使用方法的返回值就會警告，目前 swift3 已經支援該特性了。oc中也可以通過定義這個attribute來支援。

attribute((availability(swift, unavailable, message=_msg)))

OC 的方法不能在 Swift 中使用。

attribute((cleanup(…))) 作用域結束時自動執行一個指定方法

作用域結束包括大括號結束，return，goto，break，exception 等情況。這個動作是先於這個物件的 dealloc 呼叫的。

Reactive Cocoa 中有個比較好的使用範例，@onExit 這個巨集，定義如下：

#define onExit \

rac_keywordify \

__strong rac_cleanupBlock_t metamacro_concat(rac_exitBlock_, __LINE__) __attribute__((cleanup(rac_executeCleanupBlock), unused)) = ^

static inline void rac_executeCleanupBlock (__strong rac_cleanupBlock_t *block) {

(*block)();

}

這樣可以在就可以很方便的把需要成對出現的程式碼寫在一起了。同樣可以在 Reactive Cocoa 看到其使用

if (property != NULL) {

rac_propertyAttributes *attributes = rac_copyPropertyAttributes(property);

if (attributes != NULL) {

@onExit {

free(attributes);

};

BOOL isObject = attributes->objectClass != nil || strstr(attributes->type, @encode(id)) == attributes->type;

BOOL isProtocol = attributes->objectClass == NSClassFromString(@"Protocol");

BOOL isBlock = strcmp(attributes->type, @encode(void(^)())) == 0;

BOOL isWeak = attributes->weak;

shouldAddDeallocObserver = isObject && isWeak && !isBlock && !isProtocol;

}

可以看出 attributes 的設定和釋放都在一起使得程式碼的可讀性得到了提高。

attribute((overloadable)) 方法過載

能夠在 c 的函式上實現方法過載。即同樣的函式名函式能夠對不同引數在編譯時能夠自動根據引數來選擇定義的函式

__attribute__((overloadable)) void printArgument(int number){

NSLog(@"Add Int %i", number);

}

__attribute__((overloadable)) void printArgument(NSString *number){

NSLog(@"Add NSString %@", number);

}

__attribute__((overloadable)) void printArgument(NSNumber *number){

NSLog(@"Add NSNumber %@", number);

}

attribute((objc_designated_initializer)) 指定內部實現的初始化方法

如果是 objc_designated_initializer 初始化的方法必須呼叫覆蓋實現 super 的 objc_designated_initializer 方法。
如果不是 objc_designated_initializer 的初始化方法，但是該類有 objc_designated_initializer 的初始化方法，那麼必須呼叫該類的 objc_designated_initializer 方法或者非 objc_designated_initializer 方法，而不能夠呼叫 super 的任何初始化方法。

attribute((objc_subclassing_restricted)) 指定不能有子類

相當於 Java 裡的 final 關鍵字，如果有子類繼承就會出錯。

attribute((objc_requires_super)) 子類繼承必須呼叫 super

宣告後子類在繼承這個方法時必須要呼叫 super，否則會出現編譯警告，這個可以定義一些必要執行的方法在 super 裡提醒使用者這個方法的內容時必要的。

attribute((const)) 重複呼叫相同數值引數優化返回

用於數值型別引數的函式，多次呼叫相同的數值型引數，返回是相同的，只在第一次是需要進行運算，後面只返回第一次的結果，這時編譯器的一種優化處理方式。

attribute((constructor(PRIORITY))) 和 attribute((destructor(PRIORITY)))

PRIORITY 是指執行的優先順序，main 函式執行之前會執行 constructor，main 函式執行後會執行 destructor，+load 會比 constructor 執行的更早點，因為動態連結器載入 Mach-O 檔案時會先載入每個類，需要 +load 呼叫，然後才會呼叫所有的 constructor 方法。

通過這個特性，可以做些比較好玩的事情，比如說類已經 load 完了，是不是可以在 constructor 中對想替換的類進行替換，而不用加在特定類的 +load 方法裡。

Clang 警告處理

先看看這個

#pragma clang diagnostic push

#pragma clang diagnostic ignored "-Wdeprecated-declarations"

sizeLabel = [self sizeWithFont:font constrainedToSize:size lineBreakMode:NSLineBreakByWordWrapping];

#pragma clang diagnostic pop

如果沒有#pragma clang 這些定義，會報出 sizeWithFont 的方法會被廢棄的警告，這個加上這個方法當然是為了相容老系統，加上 ignored “-Wdeprecated-declarations” 的作用是忽略這個警告。通過 clang diagnostic push/pop 可以靈活的控制程式碼塊的編譯選項。

使用 libclang 來進行語法分析

使用 libclang 裡面提供的方法對原始檔進行語法分析，分析語法樹，遍歷語法數上每個節點。寫個 python 指令碼來呼叫 clang

pip install clang

#!/usr/bin/python

# vim: set fileencoding=utf-8

import clang.cindex

import asciitree

import sys

def node_children(node):

return (c for c in node.get_children() if c.location.file == sys.argv[1])

def print_node(node):

text = node.spelling or node.displayname

kind = str(node.kind)[str(node.kind).index('.')+1:]

return '{} {}'.format(kind, text)

if len(sys.argv) != 2:

print("Usage: dump_ast.py [header file name]")

sys.exit()

clang.cindex.Config.set_library_file('/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib')

index = clang.cindex.Index.create()

translation_unit = index.parse(sys.argv[1], ['-x', 'objective-c'])

print asciitree.draw_tree(translation_unit.cursor,

lambda n: list(n.get_children()),

lambda n: "%s (%s)" % (n.spelling or n.displayname, str(n.kind).split(".")[1]))

基於語法樹的分析還可以針對字串做加密。

LibTooling 對語法樹完全的控制

因為 LibTooling 能夠完全控制語法樹，那麼可以做的事情就非常多了，比如檢查命名是否規範，還能夠進行語言的轉換，比如把 OC 語言轉成JS或者 Swift 。可以用這個 tools 自己寫個工具去遍歷。

#include "clang/Driver/Options.h"
#include "clang/AST/AST.h"
#include "clang/AST/ASTContext.h"
#include "clang/AST/ASTConsumer.h"
#include "clang/AST/RecursiveASTVisitor.h"
#include "clang/Frontend/ASTConsumers.h"
#include "clang/Frontend/FrontendActions.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
#include "clang/Rewrite/Core/Rewriter.h"

using namespace std;
using namespace clang;
using namespace clang::driver;
using namespace clang::tooling;
using namespace llvm;

Rewriter rewriter;
int numFunctions = 0;

static llvm::cl::OptionCategory StatSampleCategory("Stat Sample");

class ExampleVisitor : public RecursiveASTVisitor<ExampleVisitor> {
private:
    ASTContext *astContext; // used for getting additional AST info

public:
    explicit ExampleVisitor(CompilerInstance *CI) 
      : astContext(&(CI->getASTContext())) // initialize private members
    {
        rewriter.setSourceMgr(astContext->getSourceManager(), astContext->getLangOpts());
    }

virtual bool VisitFunctionDecl(FunctionDecl *func) {
        numFunctions++;
        string funcName = func->getNameInfo().getName().getAsString();
        if (funcName == "do_math") {
            rewriter.ReplaceText(func->getLocation(), funcName.length(), "add5");
            errs() << "** Rewrote function def: " << funcName << "\n";
        }    
        return true;
    }

virtual bool VisitStmt(Stmt *st) {
        if (ReturnStmt *ret = dyn_cast<ReturnStmt>(st)) {
            rewriter.ReplaceText(ret->getRetValue()->getLocStart(), 6, "val");
            errs() << "** Rewrote ReturnStmt\n";
        }        
        if (CallExpr *call = dyn_cast<CallExpr>(st)) {
            rewriter.ReplaceText(call->getLocStart(), 7, "add5");
            errs() << "** Rewrote function call\n";
        }
        return true;
    }
};

class ExampleASTConsumer : public ASTConsumer {
private:
    ExampleVisitor *visitor; // doesn't have to be private

public:
    // override the constructor in order to pass CI
    explicit ExampleASTConsumer(CompilerInstance *CI)
        : visitor(new ExampleVisitor(CI)) // initialize the visitor
    { }

// override this to call our ExampleVisitor on the entire source file
    virtual void HandleTranslationUnit(ASTContext &Context) {
        visitor->TraverseDecl(Context.getTranslationUnitDecl());
    }
};

class ExampleFrontendAction : public ASTFrontendAction {
public:
    virtual std::unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI, StringRef file) {
         return llvm::make_unique<ExampleASTConsumer>(&CI); // pass CI pointer to ASTConsumer
    }
};

int main(int argc, const char **argv) {
    // parse the command-line args passed to your code
    CommonOptionsParser op(argc, argv, StatSampleCategory);        
    // create a new Clang Tool instance (a LibTooling environment)
    ClangTool Tool(op.getCompilations(), op.getSourcePathList());

// run the Clang Tool, creating a new FrontendAction (explained below)
    int result = Tool.run(newFrontendActionFactory<ExampleFrontendAction>().get());

errs() << "\nFound " << numFunctions << " functions.\n\n";
    // print out the rewritten source code ("rewriter" is a global var.)
    rewriter.getEditBuffer(rewriter.getSourceMgr().getMainFileID()).write(errs());
    return result;
}

#include "clang/Driver/Options.h"

#include "clang/AST/AST.h"

#include "clang/AST/ASTContext.h"

#include "clang/AST/ASTConsumer.h"

#include "clang/AST/RecursiveASTVisitor.h"

#include "clang/Frontend/ASTConsumers.h"

#include "clang/Frontend/FrontendActions.h"

#include "clang/Frontend/CompilerInstance.h"

#include "clang/Tooling/CommonOptionsParser.h"

#include "clang/Tooling/Tooling.h"

#include "clang/Rewrite/Core/Rewriter.h"

using namespace std;

using namespace clang;

using namespace clang::driver;

using namespace clang::tooling;

using namespace llvm;

Rewriter rewriter;

int numFunctions = 0;

static llvm::cl::OptionCategory StatSampleCategory("Stat Sample");

class ExampleVisitor : public RecursiveASTVisitor<ExampleVisitor> {

private:

ASTContext *astContext; // used for getting additional AST info

public:

explicit ExampleVisitor(CompilerInstance *CI)

: astContext(&(CI->getASTContext())) // initialize private members

{

rewriter.setSourceMgr(astContext->getSourceManager(), astContext->getLangOpts());

}

virtual bool VisitFunctionDecl(FunctionDecl *func) {

numFunctions++;

string funcName = func->getNameInfo().getName().getAsString();

if (funcName == "do_math") {

rewriter.ReplaceText(func->getLocation(), funcName.length(), "add5");

errs() << "** Rewrote function def: " << funcName << "\n";

}

return true;

}

virtual bool VisitStmt(Stmt *st) {

if (ReturnStmt *ret = dyn_cast<ReturnStmt>(st)) {

rewriter.ReplaceText(ret->getRetValue()->getLocStart(), 6, "val");

errs() << "** Rewrote ReturnStmt\n";

}

if (CallExpr *call = dyn_cast<CallExpr>(st)) {

rewriter.ReplaceText(call->getLocStart(), 7, "add5");

errs() << "** Rewrote function call\n";

}

return true;

}

};

class ExampleASTConsumer : public ASTConsumer {

private:

ExampleVisitor *visitor; // doesn't have to be private

public:

// override the constructor in order to pass CI

explicit ExampleASTConsumer(CompilerInstance *CI)

: visitor(new ExampleVisitor(CI)) // initialize the visitor

{ }

// override this to call our ExampleVisitor on the entire source file

virtual void HandleTranslationUnit(ASTContext &Context) {

visitor->TraverseDecl(Context.getTranslationUnitDecl());

}

};

class ExampleFrontendAction : public ASTFrontendAction {

public:

virtual std::unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI, StringRef file) {

return llvm::make_unique<ExampleASTConsumer>(&CI); // pass CI pointer to ASTConsumer

}

};

int main(int argc, const char **argv) {

// parse the command-line args passed to your code

CommonOptionsParser op(argc, argv, StatSampleCategory);

// create a new Clang Tool instance (a LibTooling environment)

ClangTool Tool(op.getCompilations(), op.getSourcePathList());

// run the Clang Tool, creating a new FrontendAction (explained below)

int result = Tool.run(newFrontendActionFactory<ExampleFrontendAction>().get());

errs() << "\nFound " << numFunctions << " functions.\n\n";

// print out the rewritten source code ("rewriter" is a global var.)

rewriter.getEditBuffer(rewriter.getSourceMgr().getMainFileID()).write(errs());

return result;

}

ClangPlugin

通過自己寫個外掛，可以將這個外掛新增到編譯的流程中，對編譯進行控制，可以在 LLVM 的這個目錄下檢視一些範例 llvm/tools/clang/tools

孫源主導的動態化方案 DynamicCocoa 中就是使用了一個將 OC 原始碼轉 JS 的外掛來進行程式碼的轉換。

滴滴的王康在做瘦身時也實現了一個自定義的 clang 外掛，具體自定義外掛的實現可以檢視他的這文章《基於clang外掛的一種iOS包大小瘦身方案》

編譯後生成的二進位制內容 Link Map File

在 Build Settings 裡設定 Write Link Map File 為 Yes 後每次編譯都會在指定目錄生成這樣一個檔案。檔案內容包含 Object files，Sections，Symbols。下面分別說說這些內容

Object files

這個部分的內容都是 .m 檔案編譯後的 .o 和需要 link 的 .a 檔案。前面是檔案編號，後面是檔案路徑。

Sections

這裡描述的是每個 Section 在可執行檔案中的位置和大小。每個 Section 的 Segment 的型別分為 TEXT 程式碼段和 DATA 資料段兩種。

Symbols

Symbols 是對 Sections 進行了再劃分。這裡會描述所有的 methods，ivar 和字串，及它們對應的地址，大小，檔案編號資訊。

每次編譯後生成的 dSYM 檔案

在每次編譯後都會生成一個 dSYM 檔案，程式在執行中通過地址來呼叫方法函式，而 dSYM 檔案裡儲存了函式地址對映，這樣呼叫棧裡的地址可以通過 dSYM 這個對映表能夠獲得具體函式的位置。一般都會用來處理 crash 時獲取到的呼叫棧 .crash 檔案將其符號化。

可以通過 Xcode 進行符號化，將 .crash 檔案，.dSYM 和 .app 檔案放到同一個目錄下，開啟 Xcode 的 Window 選單下的 organizer，再點選 Device tab，最後選中左邊的 Device Logs。選擇 import 將 .crash 檔案匯入就可以看到 crash 的詳細 log 了。

還可以通過命令列工具 symbolicatecrash 來手動符號化 crash log。同樣先將 .crash 檔案，.dSYM 和 .app 檔案放到同一個目錄下，然後輸入下面的命令

1 2	export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer symbolicatecrash appName.crash appName.app > appName.log

Mach-O 檔案

記錄編譯後的可執行檔案，物件程式碼，共享庫，動態載入程式碼和記憶體轉儲的檔案格式。不同於 xml 這樣的檔案，它只是二進位制位元組流，裡面有不同的包含元資訊的資料塊，比如位元組順序，cpu 型別，塊大小等。檔案內容是不可以修改的，因為在 .app 目錄中有個 _CodeSignature 的目錄，裡面包含了程式程式碼的簽名，這個簽名的作用就是保證簽名後 .app 裡的檔案，包括資原始檔，Mach-O 檔案都不能夠更改。

Mach-O 檔案包含三個區域

Mach-O Header：包含位元組順序，magic，cpu 型別，載入指令的數量等
Load Commands：包含很多內容的表，包括區域的位置，符號表，動態符號表等。每個載入指令包含一個元資訊，比如指令型別，名稱，在二進位制中的位置等。
Data：最大的部分，包含了程式碼，資料，比如符號表，動態符號表等。

Mach-O 檔案的解析

解析前先看看可以描述該檔案的結構體

struct mach_header {

uint32_t magic;

cpu_type_t cputype;

cpu_subtype_t cpusubtype;

uint32_t filetype;

uint32_t ncmds;

uint32_t sizeofcmds;

uint32_t flags;

};

struct segment_command {

uint32_t cmd;

uint32_t cmdsize;

char segname[16];

uint32_t vmaddr;

uint32_t vmsize;

uint32_t fileoff;

uint32_t filesize;

vm_prot_t maxprot;

vm_prot_t initprot;

uint32_t nsects;

uint32_t flags;

};

根據這個結構體，需要先取出 magic，然後根據偏移量取出其它的資訊。遍歷 ncmds 能夠獲得所有的 segment。cputype 包含了 CPU_TYPE_I386，CPU_TYPE_X86_64，CPU_TYPE_ARM，CPU_TYPE_ARM64 等多種 CPU 的型別。

dyld動態連結

生成可執行檔案後就是在啟動時進行動態連結了，進行符號和地址的繫結。首先會載入所依賴的 dylibs，修正地址偏移，因為 iOS 會用 ASLR 來做地址偏移避免攻擊，確定 Non-Lazy Pointer 地址進行符號地址繫結，載入所有類，最後執行 load 方法和 clang attribute 的 constructor 修飾函式。

附：安裝編譯 LLVM

多種獲取方式

官網：http://releases.llvm.org/download.html

svn

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm

cd llvm/tools

svn co http://llvm.org/svn/llvm-project/cfe/trunk clang

cd ../projects

svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt

cd ../tools/clang/tools

svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra

git

git clone http://llvm.org/git/llvm.git

cd llvm/tools

git clone http://llvm.org/git/clang.git

cd ../projects

git clone http://llvm.org/git/compiler-rt.git

cd ../tools/clang/tools

git clone http://llvm.org/git/clang-tools-extra.git

安裝

brew install cmake

mkdir build

cmake /path/to/llvm/source

cmake --build .

iOS clang編譯.m
2017-03-08
iOS編譯
(Xcode) 編譯器小白筆記 – LLVM前端Clang
2019-03-03
XCode編譯筆記LVM前端
(Xcode) 編譯器小白筆記 - LLVM前端Clang
2018-11-19
XCode編譯筆記LVM前端
CentOS 6.4 編譯安裝LLVM3.3，Clang和Libc++
2013-06-18
CentOS編譯LVMC++
llvm 編譯
2018-02-11
LVM編譯
GUN、GCC、LLVM和Clang
2018-06-15
GCLVM
gcc 編譯器與 clang 編譯器
2016-11-27
GC編譯
LLVM Clang 學習筆記
2017-12-13
LVM筆記
深入淺出iOS編譯
2018-12-26
iOS編譯
深入剖析Java即時編譯器（上）
2019-03-13
Java編譯
windows上使用clang編譯程式
2017-09-18
Windows編譯
clang的編譯器有點智慧
2016-11-28
編譯
LLVM與Clang的一些事兒
2017-12-25
LVM
NDK clang編譯器的一個bug
2020-05-10
編譯
編譯器GCC與Clang的異同
2018-02-04
編譯GC
深入剖析Vue原始碼 - 例項掛載,編譯流程
2019-05-04
Vue原始碼編譯
iOS #pragma clang
2017-12-28
iOS
從Oclint開始接觸Clang編譯
2018-01-18
編譯
iOS 深入剖析多執行緒
2017-12-19
iOS執行緒
Java反編譯器剖析
2014-02-07
Java編譯
[譯]iOS編譯器
2018-02-27
iOS編譯
iOS學習之深入理解程式編譯過程
2017-12-25
iOS編譯
什麼是 LLVM？ Swift、Rust、Clang等背後的力量 - infoworld
2022-01-08
LVMSwiftRust
LLVM編譯器中的內建(built-in)函式
2019-05-05
LVM編譯UI函式
LLVM之父分享發明編譯器的經驗 - hpcwire
2021-12-28
LVM編譯
什麼是 LLVM？Swift, Rust, Clang 等語言背後的支援
2018-02-27
LVMSwiftRust
在windows上用mingw w64編譯配置llvm
2017-01-23
Windows編譯LVM
使用 LLVM 框架建立有效的編譯器，第 2 部分
2012-08-01
LVM框架編譯
使用 LLVM 框架建立一個工作編譯器，第 1 部分
2012-07-18
LVM框架編譯
反編譯 iOS APP
2018-01-03
編譯iOSAPP
記一起由 Clang 編譯器優化觸發的 Crash
2020-12-11
編譯優化
clang在編譯時指定目標檔案所需的最低macOS版本
2022-11-05
編譯Mac
Clojure 執行原理之編譯器剖析
2017-02-05
編譯
llvm和mingw-w64配合編譯的奇怪問題
2016-12-12
LVM編譯
利用ld.gold將程式編譯成llvm中的Bitcode
2017-07-20
Go編譯LVM
深入分析 Javac 編譯原理
2018-09-17
Java編譯原理
記一起由 Clang 編譯器最佳化觸發的 Crash
2020-12-10
編譯
Hadoop2.x原始碼－編譯剖析
2015-10-29
Hadoop原始碼編譯

深入剖析 iOS 編譯 Clang / LLVM

編譯流程

Clang 編譯 .m 檔案

構建 Target

Target 在 Build 過程的控制

Build Phases

Build Rules

Build Settings

pbxproj工程檔案

Clang Static Analyzer靜態程式碼分析

Clang Attributes

attribute((format(NSString, F, A))) 格式化字串

attribute((deprecated(s))) 版本棄用提示

attribute((availability(os,introduced=m,deprecated=n, obsoleted=o,message=”” VA_ARGS))) 指明使用版本範圍

attribute((unavailable(…))) 方法不可用提示

attribute((unused))

attribute((warn_unused_result))

attribute((availability(swift, unavailable, message=_msg)))

attribute((cleanup(…))) 作用域結束時自動執行一個指定方法

attribute((overloadable)) 方法過載

attribute((objc_designated_initializer)) 指定內部實現的初始化方法

attribute((objc_subclassing_restricted)) 指定不能有子類

attribute((objc_requires_super)) 子類繼承必須呼叫 super

attribute((const)) 重複呼叫相同數值引數優化返回

attribute((constructor(PRIORITY))) 和 attribute((destructor(PRIORITY)))

Clang 警告處理

使用 libclang 來進行語法分析

LibTooling 對語法樹完全的控制

ClangPlugin

編譯後生成的二進位制內容 Link Map File

Object files

Sections

Symbols

每次編譯後生成的 dSYM 檔案

Mach-O 檔案

Mach-O 檔案的解析

dyld動態連結

附：安裝編譯 LLVM

多種獲取方式

安裝

相關文章