您好,登錄后才能下訂單哦!
原文出自【聽云技術(shù)博客】:http://blog.tingyun.com/web/article/detail/1346
前言
最近看 ObjC的runtime 是怎么實現(xiàn) +load 鉤子函數(shù)的實現(xiàn)。進而引申分析了 dyld 處理 Mach-O 的這部分機制。
1.簡單分析 Mach-O 在dyld 中是如何被加載到內(nèi)存中的;
2.分析了 +load 的 特殊加載時機;
+ load
上圖的調(diào)用棧告訴我們哪些函數(shù)被調(diào)用了。
dyld 是Apple 的動態(tài)鏈接器;在 xnu 內(nèi)核為程序啟動做好準備后,就會將 PC 控制權(quán)交給 dyld 負責(zé)剩下的工作 (dyld 是運行在 用戶態(tài)的, 這里由 內(nèi)核態(tài) 切到了用戶態(tài))。
每當有新的鏡像加載之后,都會執(zhí)行 load-p_w_picpaths 方法進行回調(diào),這里的回調(diào)是在整個ObjC runtime 初始化時 -objc-init 注冊的 :
有新的鏡像被 map 到 runtime 時,調(diào)用 load-p_w_picpaths 方法,并傳入最新鏡像的信息列表 infoList:
這里的鏡像就是 一些 System framework 的二進制。
進入 下圖函數(shù) load-p_w_picpaths-nolock 查找 load 函數(shù)
調(diào)用 prepare-load-methods 對 load 方法的調(diào)用進行準備(將需要調(diào)用 load 方法的類添加到一個列表中)
調(diào)用 -getObjc2NonlazyClassList 獲取所有的類的列表之后,會通過 remapClass 獲取類對應(yīng)的指針,然后調(diào)用 schedule-class-load 遞歸地 將當前類和沒有調(diào)用 + load 父類進入列表。
在執(zhí)行 add-class-to-loadable-list(cls) 將當前類加入加載列表之前,會先把父類加入待加載的列表,保證父類在子類前調(diào)用 load 方法。
在將鏡像加載到運行時、對 load 方法的準備就緒,執(zhí)行 call-load-methods,開始調(diào)用 load 方法:
其中 call-class-loads 會從一個待加載的類列表 loadable-classes 中尋找對應(yīng)的類,然后找到 @selector(load) 的實現(xiàn)并執(zhí)行。
分析到這里,已經(jīng)能得知 load 函數(shù)是如何被調(diào)用的。
接下來分析 dyld 這部分怎么加載鏡像的
1.1 數(shù)據(jù)結(jié)構(gòu)
mach-o 文件頭 操作。
1.2 ImageLoader
每一個加載的 Mach-O 文件都會存在這樣一個ImageLoader 的 實例,上圖可以看出 這里ImageLoader是一個抽象類,每一種具體的Mach-O 文件都會繼承 ImageLoader類, 繼承關(guān)系 如下圖:
在加載時會根據(jù)Mach-O的格式不同選擇生成不用的實例。
1.3 -main
在調(diào)用-main 函數(shù)之后,做了一下幾件事情:
選擇運行環(huán)境(iOS 模擬器)
初始化數(shù)據(jù)、設(shè)置全局變量、上下文信息
檢查文件是否Restricted
走完這些流程,就會調(diào)用 instantiateFromLoadedImage 函數(shù),開始加載Mach-O 并且實例化 為 ImageLoader。
1.4 instantiateFromLoadedImage
這個函數(shù)做了三件事情:
檢查Mach-O 文件是否合法
初始化 ImageLoader 實例
調(diào)用addImage 函數(shù)添加 初始化后的實例到管理模塊中
1.5 isCompatibleMachO
Mach-O 文件的合法性檢查:
mach-header 中的 cputype與當前運行的CPU 版本是否支持
mach-header 中的 subtype 在該CPU 架構(gòu)下的所有版本都可以支持
cputype 就是CPU 平臺, x86,ARM ,POWERPC 等, 而subtype 就是同一個平臺下的不同版本, 例如:arm7,arm7.
1.6 ImageLoaderMachO: : instantiateMainExecutable
該函數(shù)主要通過 sniffLoadCommands 函數(shù)來判斷 Mach-O 文件是否是壓縮過的,然后分別 選擇不同的 子類實例化。
1.7 sniffLoadCommands
這個函數(shù)主要做兩件事情
判斷Mach-O文件是classic的還是compressed的。
獲取mach-O文件的segment的數(shù)量。
1.8 ImageLoaderMachOClassic: :instantiateMainExecutable
classic 與 compressed 的初始化大同小異,先分析Classic 的實現(xiàn)
可以看到加載的核心代碼 還在 instantiateStart 函數(shù)中
1.9 instantiateStart
這里仍然沒有出現(xiàn)加載的核心代碼,只是根據(jù)之前獲得的數(shù)據(jù)申請分配了內(nèi)存,并計算 segments的 指針。 ImageLoaderMachOClassic 的構(gòu)造函數(shù)才是加載 的核心邏輯。
2.0 ImageLoaderMachOClassic
根據(jù)Mach-O 文件 segments 將數(shù)據(jù)加載到 內(nèi)存中, 任何返回 調(diào)用 addImage 函數(shù)。
2.1 addImage
這個函數(shù)只是做了數(shù)據(jù)更新
將p_w_picpath 添加到管理容器中
更新了內(nèi)存分布的信息
end
整個加載過程基本分為三個步驟:
合法加測
解析Mach-O文件頭信息,將segments 的具體信息 構(gòu)建到p_w_picpath 的實例中
添加p_w_picpath 到管理容器
根據(jù) dyld的源代碼的粗略分析, 更多信息需要分析 xnu 內(nèi)核代碼。
參考
ObjC runtime 源代碼
dyld 源代碼
《Mac OSX and iOS Internals》
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。