從Swift橋接檔案到Clang-LLVM
前言
今天在Swift
工程中不小心建立了一個OC
檔案,於是乎提示我建立一個橋接檔案,那麼為什麼需要建立橋接檔案呢,它的原理又是什麼呢?
開啟百度一搜,全是教你怎麼建立橋接檔案的,似乎找不到答案~
LVVM - Low Level Virtual Machine
Clang - C Lange Family Frontend for LVVM
編譯器探究
- GCC
GNU編譯器套件(GNU Compiler Collection)包括C、C++、Objective-C、Fortran、Java、Ada和Go語言的前端,也包括了這些語言的庫(如libstdc++、libgcj等等)
早起的OC 程式設計師都感受過GCC編譯程式,但是蘋果為什麼好好的GCC不用,自己要搞一套呢?
1.GCC 的 Objective-C Frontend不給力:GCC的前端不是蘋果提供維護的,想要新增一些語法提示等功能還得去求GCC的前端去做。
2.GCC 外掛、工具、IDE的支援薄弱:很多編譯器特性沒有,自動補全、程式碼提示、warning、靜態分析等這些流程不是很給力,都是需要IDE呼叫底層命令完成的,結果需要以外掛的形式暴露出來,這一塊GCC做的不是很好。
3.GCC 編譯效率和效能不足:Apple的Clang出來以後,其編譯效率是GCC的3倍,編譯器效能好,編譯出的檔案小。
4.Apple要收回去工具鏈的控制 (lldb, lld…): Apple在早起從GCC前端到LLVM後端的編譯器,到Clang-LVVM的編譯器,以後後來的GDB的替換,一步一步收回對編譯工具鏈的控制,也為Swift
- Three-Phase 編譯器架構
上圖是最簡單的三段式編譯器架構。
首先,我們看到source
是我們的原始碼,進入編譯器的前端Frontend
;在前端完成之後,就進入優化器這一模組;優化完成之後進入後端這一模組;在這全部完成之後,根據你的架構是x86,armv7等生產機器碼。
但是會有一個問題:
M (Language) * N (Target) = M * N (Compilers)
就是如果你有M種語言(C、C++、Objective-C…),N種架構(armv7、armv7s、arm64、i386、x86_64…),那麼你就有M * N中編譯方式需要處理,顯然是不合理的。
- apple 的
Clang/Swift - LLVM
編譯器架構:
其中優化器部分(Common Optimizer)是共享的。而對於每一種語言都有其前端部分,假如新有一門語言,只需要實現該語言的前端模組;如果新出一臺裝置,它的架構不同,那麼也只需要單獨完成其後端模組即可。改動非常小,不會做重複的工作。
下面詳解:
藍色的部分:C語言家族系列的前端,屬於Clang部分。
綠色的部分: Swift語言的前端,其中還包含自己的SIL中間語言和Optimzer中間語言的優化過程。
紫色的部分: 優化階段和後端模組統一是LLVM部分。
- 程式碼規模
Clang + LLVM 程式碼模組總共有400W行程式碼,其中主體部分是C++寫的,大概有235W行。如果將所有的target,lib等檔案編譯出來,大概有近20G的大小:
對比Swift Frontend 程式碼規模,就少很多,只有43W行左右。可能在後端,比如優化器策略,生成機器碼部分就有很多程式碼:
- Clang命令
Clang在概念上是編譯器前端,同時,在命令列中也作為一個“黑盒”的 Driver;
它封裝了編譯管線、前端命令、LLVM命令、Toolchain命令等,即一個Clang走天下;
方便從GCC遷移過來。
當我們點選run命令以後,如下圖:
就是我們在build setting中的一些設定,組裝成命令,下面可以看到是一個 oc檔案在arc環境下的編譯過程:
- 拆解編譯過程
#import <Foundation/Foundation.h>
int main() {
@autoreleasepool {
id obj = [NSObject new];
NSLog(@"Hellow world: %@", obj);
}
}
1.Preprocess - 預處理
import 標頭檔案,include標頭檔案等
macro巨集展開
處理’#’大頭的預處理指令,如 #if,#elseif等
終端輸入:
$ clang -E main.m
只會做預處理步驟,不往後面走,如下
可以看到一個頭檔案要匯入很多行程式碼,這裡就要說到pch檔案。本身Apple給出這個檔案,是讓我們放入Foundation
或者UIKit
等這些根本不會變的庫,優化編譯過程,但是開發者卻各種巨集,各種標頭檔案匯入,導致編譯速度很慢。以至於後來蘋果刪除了這個檔案,只能開發者自己建立。但是蘋果提供modules這個概念,可以通過以下命令開啟:
$ clang -E -fmodules main.m
預設把一些檔案打包成庫檔案, 在build setting中預設開啟的,我們可以用@import Foundation:
2.Lexical Analysis - 詞法分析
詞法分析,也作Lex 或者 Tokenization
將預處理過得程式碼文字轉化為Token流
不會校驗語義
可以在終端輸入以下命令:
$ clang -fmodules -fayntax-only -Xclang -dump-tokens main.m
如下圖:
3.Analysis - 語法分析
語法分析,在Clang中有Parser和Sema兩個模組配合完成,驗證語法是否正確,並給出正確的提示。這就是Clang標榜GCC,自己的語法提示友好的體現。
根據當前的語法,生成語意節點,並將所有節點組合成抽象語法書(AST)
輸入命令:
$ clang -fmodules -fsyntax-only -Xclang -ast-dump main.m
如下圖:
可以通過語法樹,反寫回原始碼,如下圖:
4.Static Analysis - 靜態分析(不是必須的)
通過語法書進行程式碼靜態分析,找出非語法性錯誤
模擬程式碼執行路徑,分析出 contro-flow graph (CFG)
預置了常用的 Checker
在Xcode中如下操作可以實現:
5.CodeGen - IR 程式碼生成
CodeGen負責將語法樹從頂至下遍歷,翻譯成LLVM IR,LLVMIR 是Frontend的輸入,也是LLVM Backend 的輸入,是前後端的橋接語言。
與Objective-C Runtime 橋接
①Class / Meta Class / Protocol / Category 記憶體結構生成,並存放在指定 session中(如Class: _DATA, _objc_classrefs)
②Method / Ivar / Property 記憶體結構生成
③組成 method_list / ivar_list / property_list並填入Class
④Non-Fragile ABI: 為每個Ivar合成 OBJC_IVAR_$_偏移常量
⑤存取 Ivar的語句(ivar = 123; int a = _ivar;) 轉寫成base + OBJC_IVAR$_的形式
⑥將語法樹中的 ObjCMessageExpr 翻譯成相應版本的objc_msgSend,對super關鍵字的呼叫翻譯成objc_msgSendSuper
⑦處理@synthsynthesize
⑧生成 block_layout
的資料結構
⑨變數 capture (__block/ __weak)
10.生成_block_invoke
函式
11.ARC: 分析物件引用關係,將 objc_storeStrong/ objc_storeWeak
等ARC 程式碼插入
12.將 ObjCAutoreleasePoolStmt
轉譯成objc_autoreleasePoolPush/Pop
13.實現自動呼叫[super dealloc]
14.為每個擁有 ivar 的Class 合成.cxx_destructor
方法來自動釋放類的成員變數,代替MRC 時代下的”self.xxx = nil”
舉個栗子,嘿嘿:
終端輸入:
$ clang -S -fobjc-arc -emit-llvm main.m -o main.m
輸入如下:
介於C和彙編的中間形態。
如果加入優化:
$ clang -O3 -S -fobjc-arc -emit-llvm main.m -o main.m
明顯感覺少了很多。
6. LVVM Bitcode - 生成位元組碼
輸入命令:
$ clang -emit-llvm -c main.m -o main.bc
相信大家在iOS 9之後都聽過這個概念,其實就是對IR生成二進位制的過程。
7.Assemble - 生成Target相關彙編
終端輸入:
$ clang -S -fobjc-arc main.m -o main.s
如下圖:
彙編程式碼。
8.Assemble - 生成Target相關 Object(Mach-o)
終端輸入:
$ clang -fmodules -c main.m -o main.o
彙編的main.o的形式。
9.Link 生成 Executable
終端輸入:
$ clang main.m -o main
$ ./main
總結一下吧:
至此,我猜測可能橋接檔案是在Clang階段,將OC檔案進行編譯,生成語法樹,然後再返成Swift能識別的類檔案。
- 我們能在Clang上做什麼?
Apple給我們留了3個介面:
1.LibClang
功能:
①C 的API來訪問Clang的上層能力,比如獲取Tokens、遍歷語法樹、程式碼補全、獲取診斷資訊;
②API穩定,不受Clang原始碼更新影響
③只有上層的語法樹可以訪問,不能獲取到全部資訊
④使用原始的 C的API
⑤指令碼語言: 使用官方提供的 python binding 或開源的 node-js / ruby binding
⑥Objective-C: 開源庫 ClangKit
2.LibTooling
①對語法樹 有完全的控制權
②可作為一個 standalone 命令單獨使用,如 clang-format
③需要使用C++且對Clang原始碼熟悉
3.ClangPlugin
①對語法樹有完全的控制權
②作為外掛注入到編譯流程中,可以影響build和決定編譯過程
③需要使用C++且對Clang原始碼熟悉
結語
最後感謝孫源(我就叫Sunny怎麼了)的分享,而且希望感興趣的小夥伴可以閱讀《程式設計師的自我修養》這本書,想要高階資料,那麼“龍書”將是你的不二之選。
參考資料:
- 《Getting Started with LLVM Core Libraries》
- 《LLVM Cookbook》