前言
今天在Swift
工程中不小心創(chuàng)建了一個OC
文件犬金,于是乎提示我創(chuàng)建一個橋接文件份蝴,那么為什么需要創(chuàng)建橋接文件呢,它的原理又是什么呢衡未?
打開百度一搜尸执,全是教你怎么創(chuàng)建橋接文件的,似乎找不到答案~
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、靜態(tài)分析等這些流程不是很給力翔横,都是需要IDE調(diào)用底層命令完成的读跷,結(jié)果需要以插件的形式暴露出來,這一塊GCC做的不是很好禾唁。
3.GCC 編譯效率和性能不足:Apple的Clang出來以后效览,其編譯效率是GCC的3倍,編譯器性能好荡短,編譯出的文件小丐枉。
4.Apple要收回去工具鏈的控制 (lldb, lld...): Apple在早起從GCC前端到LLVM后端的編譯器,到Clang-LVVM的編譯器掘托,以后后來的GDB的替換瘦锹,一步一步收回對編譯工具鏈的控制,也為Swift
的出現(xiàn)奠定基礎。
- Three-Phase 編譯器架構(gòu)
上圖是最簡單的三段式編譯器架構(gòu)弯院。
首先辱士,我們看到source
是我們的源代碼,進入編譯器的前端Frontend
听绳;在前端完成之后颂碘,就進入優(yōu)化器這一模塊;優(yōu)化完成之后進入后端這一模塊椅挣;在這全部完成之后头岔,根據(jù)你的架構(gòu)是x86,armv7等生產(chǎn)機器碼鼠证。
但是會有一個問題:
M (Language) * N (Target) = M * N (Compilers)
就是如果你有M種語言(C切油、C++、Objective-C...)名惩,N種架構(gòu)(armv7、armv7s孕荠、arm64娩鹉、i386、x86_64...)稚伍,那么你就有M * N中編譯方式需要處理弯予,顯然是不合理的。
-
apple 的
Clang/Swift - LLVM
編譯器架構(gòu):
其中優(yōu)化器部分(Common Optimizer)是共享的个曙。而對于每一種語言都有其前端部分锈嫩,假如新有一門語言,只需要實現(xiàn)該語言的前端模塊垦搬;如果新出一臺設備呼寸,它的架構(gòu)不同,那么也只需要單獨完成其后端模塊即可猴贰。改動非常小对雪,不會做重復的工作。
下面詳解:
藍色的部分:C語言家族系列的前端米绕,屬于Clang部分瑟捣。
綠色的部分: Swift語言的前端,其中還包含自己的SIL中間語言和Optimzer中間語言的優(yōu)化過程栅干。
紫色的部分: 優(yōu)化階段和后端模塊統(tǒng)一是LLVM部分迈套。
- 代碼規(guī)模
Clang + LLVM 代碼模塊總共有400W行代碼,其中主體部分是C++寫的碱鳞,大概有235W行桑李。如果將所有的target,lib等文件編譯出來,大概有近20G的大熊皆:
對比Swift Frontend 代碼規(guī)模星岗,就少很多,只有43W行左右戒洼∏伍伲可能在后端,比如優(yōu)化器策略圈浇,生成機器碼部分就有很多代碼:
- Clang命令
Clang在概念上是編譯器前端寥掐,同時,在命令行中也作為一個“黑盒”的 Driver;
它封裝了編譯管線磷蜀、前端命令召耘、LLVM命令、Toolchain命令等褐隆,即一個Clang走天下污它;
方便從GCC遷移過來。
當我們點擊run命令以后庶弃,如下圖:
就是我們在build setting中的一些設置衫贬,組裝成命令,下面可以看到是一個 oc文件在arc環(huán)境下的編譯過程:
- 拆解編譯過程
#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
等這些根本不會變的庫,優(yōu)化編譯過程村砂,但是開發(fā)者卻各種宏栈暇,各種頭文件導入,導致編譯速度很慢箍镜。以至于后來蘋果刪除了這個文件源祈,只能開發(fā)者自己創(chuàng)建。但是蘋果提供modules這個概念色迂,可以通過以下命令打開:
$ clang -E -fmodules main.m
默認把一些文件打包成庫文件, 在build setting中默認打開的香缺,我們可以用@import Foundation:
2.Lexical Analysis - 詞法分析
詞法分析,也作Lex 或者 Tokenization
將預處理過得代碼文本轉(zhuǎn)化為Token流
不會校驗語義
可以在終端輸入以下命令:
$ clang -fmodules -fayntax-only -Xclang -dump-tokens main.m
如下圖:
3.Analysis - 語法分析
語法分析歇僧,在Clang中有Parser和Sema兩個模塊配合完成图张,驗證語法是否正確锋拖,并給出正確的提示。這就是Clang標榜GCC祸轮,自己的語法提示友好的體現(xiàn)兽埃。
根據(jù)當前的語法,生成語意節(jié)點适袜,并將所有節(jié)點組合成抽象語法書(AST)
輸入命令:
$ clang -fmodules -fsyntax-only -Xclang -ast-dump main.m
如下圖:
可以通過語法樹柄错,反寫回源碼,如下圖:
4.Static Analysis - 靜態(tài)分析(不是必須的)
通過語法書進行代碼靜態(tài)分析苦酱,找出非語法性錯誤
模擬代碼執(zhí)行路徑售貌,分析出 contro-flow graph (CFG)
預置了常用的 Checker
在Xcode中如下操作可以實現(xiàn):
5.CodeGen - IR 代碼生成
CodeGen負責將語法樹從頂至下遍歷,翻譯成LLVM IR疫萤,LLVMIR 是Frontend的輸入颂跨,也是LLVM Backend 的輸入,是前后端的橋接語言扯饶。
與Objective-C Runtime 橋接
①Class / Meta Class / Protocol / Category 內(nèi)存結(jié)構(gòu)生成恒削,并存放在指定 session中(如Class: _DATA, _objc_classrefs)
②Method / Ivar / Property 內(nèi)存結(jié)構(gòu)生成
③組成 method_list / ivar_list / property_list并填入Class
④Non-Fragile ABI: 為每個Ivar合成 OBJC_IVAR_$_偏移常量
⑤存取 Ivar的語句(ivar = 123; int a = ivar;) 轉(zhuǎn)寫成base + **OBJC_IVAR$**的形式
⑥將語法樹中的 ObjCMessageExpr 翻譯成相應版本的objc_msgSend,對super關鍵字的調(diào)用翻譯成objc_msgSendSuper
⑦處理@synthsynthesize
⑧生成 block_layout
的數(shù)據(jù)結(jié)構(gòu)
⑨變量 capture (__block/ __weak)
10.生成_block_invoke
函數(shù)
11.ARC: 分析對象引用關系尾序,將 objc_storeStrong/ objc_storeWeak
等ARC 代碼插入
12.將 ObjCAutoreleasePoolStmt
轉(zhuǎn)譯成objc_autoreleasePoolPush/Pop
13.實現(xiàn)自動調(diào)用[super dealloc]
14.為每個擁有 ivar 的Class 合成.cxx_destructor
方法來自動釋放類的成員變量蔓同,代替MRC 時代下的"self.xxx = nil"
舉個栗子,嘿嘿:
終端輸入:
$ clang -S -fobjc-arc -emit-llvm main.m -o main.m
輸入如下:
介于C和匯編的中間形態(tài)蹲诀。
如果加入優(yōu)化:
$ clang -O3 -S -fobjc-arc -emit-llvm main.m -o main.m
明顯感覺少了很多。
6. LVVM Bitcode - 生成字節(jié)碼
輸入命令:
$ 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
總結(jié)一下吧:
至此痕慢,我猜測可能橋接文件是在Clang階段,將OC文件進行編譯涌矢,生成語法樹掖举,然后再返成Swift能識別的類文件。
- 我們能在Clang上做什么娜庇?
Apple給我們留了3個接口:
1.LibClang
功能:
①C 的API來訪問Clang的上層能力塔次,比如獲取Tokens、遍歷語法樹名秀、代碼補全励负、獲取診斷信息;
②API穩(wěn)定匕得,不受Clang源碼更新影響
③只有上層的語法樹可以訪問继榆,不能獲取到全部信息
④使用原始的 C的API
⑤腳本語言: 使用官方提供的 python binding 或開源的 node-js / ruby binding
⑥Objective-C: 開源庫 ClangKit
2.LibTooling
①對語法樹 有完全的控制權(quán)
②可作為一個 standalone 命令單獨使用,如 clang-format
③需要使用C++且對Clang源碼熟悉
3.ClangPlugin
①對語法樹有完全的控制權(quán)
②作為插件注入到編譯流程中,可以影響build和決定編譯過程
③需要使用C++且對Clang源碼熟悉
結(jié)語
??最后感謝孫源(我就叫Sunny怎么了)的分享略吨,而且希望感興趣的小伙伴可以閱讀《程序員的自我修養(yǎng)》這本書集币,想要高階資料,那么“龍書”將是你的不二之選翠忠。
??如果本文中有錯誤的地方鞠苟,歡迎指正,郵箱: ed_sun0129@163.com负间,github: https://github.com/edsum偶妖!
參考資料:
http://clang.llvm.org/docs/index.html
http://blog.llvm.org/
https://www.objc.io/issues/6-build-tools/compiler/
http://llvm.org/docs/tutorial/index.html
https://github.com/loarabia/Clang-tutorial
http://lowlevelbits.org/getting-started-with-llvm/clang-on-os-x/
https://hevinaboos.wordpress.com/2013/07/23/clang-tutorial-part-i-introducation/
http://szelei.me/code-generator/
- 《Getting Started with LLVM Core Libraries》
- 《LLVM Cookbook》