方法執(zhí)行順序
我們在main函數(shù)中加了一個C++方法和一個普通的打印方法，在ViewController中重寫了load方法，思考5秒鐘，請問它們的打印先后順序是什么？
// 內(nèi)存 main() dyld image init 注冊回調(diào)通知 - dyld_start -> dyld::main() -> main()
// rax
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
NSLog(@"23333");
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
appDelegateClassName = NSStringFromClass([AppDelegate class]);
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
// load -> Cxx -> main
__attribute__((constructor)) void zgFunc(){
printf("來了 : %s \n",__func__);
}
+ load方法
@interface ViewController ()
@end
@implementation ViewController
+ (void)load{
NSLog(@"%s",__func__);
}
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
}
5,4,3,2,1...
運行程序，查看load、zgFunc、main的打印順序，下面是打印結(jié)果，通過結(jié)果可以看出其順序是load --> C++方法 --> main，我們都知道main函數(shù)是程序的入口函數(shù)，那么為什么不是main先打印呢？原來在main函數(shù)之前，蘋果還做了大量的工作，其中dyld就是其中重要的一環(huán)。
什么是dyld?
dyld 是the dynamic link editor的簡寫，翻譯過來就是動態(tài)鏈接器，是蘋果操作系統(tǒng)的一個重要的組成部分。在iOS/Mac OSX 系統(tǒng)中，僅有很少量的進程只需要內(nèi)核就能完成加載，基本上所有的進程都是動態(tài)鏈接的，所以Mach-O鏡像文件中會有很多對外部的庫和符號的引用，但是這些引用并不能直接用，在啟動時還必須要通過這些引用進行內(nèi)容的填補，這個填補工作就是由 動態(tài)鏈接器dyld來完成的，也就是符號綁定。
動態(tài)鏈接器dyld在系統(tǒng)中以一個用戶態(tài)的可執(zhí)行文件形式存在，一般應(yīng)用程序會在Mach-O 文件部分指定一個LC_LOAD_DYLINKER 的加載命令，此加載命令指定了dyld 的路徑，通常它的默認值是/usr/lib/dyld 。系統(tǒng)內(nèi)核在加載Mach-O 文件時，都需要用dyld（位于 /usr/lib/dyld ）程序進行鏈接。
dyld是開源的，感興趣可以下載查閱。dyld源碼下載
代碼編譯過程
在分析app啟動之前，我們需要先了解app代碼的編譯過程以及動態(tài)庫和靜態(tài)庫。
其中編譯過程如下圖所示，主要分為以下幾步：
源文件：載入.h、.m、.cpp等文件
預處理：替換宏，刪除注釋，展開頭文件，產(chǎn)生.i文件
編譯：將.i文件轉(zhuǎn)換為匯編語言，產(chǎn)生.s文件
匯編：將匯編文件轉(zhuǎn)換為機器碼文件，產(chǎn)生.o文件
鏈接：對.o文件中引用其他庫的地方進行引用，生成最后的可執(zhí)行文件
靜態(tài)庫可以看成是一堆對象文件(object files)的歸檔。當鏈接這樣一個庫到應(yīng)用中時，靜態(tài)鏈接器static linker將會從庫中收集這些對象文件并把它們和應(yīng)用的對象代碼一起打包到一個單獨的二進制文件中。這意味著應(yīng)用的可執(zhí)行文件大小將會隨著庫的數(shù)目增加而增長`。另外，當應(yīng)用啟動時，應(yīng)用的代碼（包含庫的代碼）將會一次性地導入到程序的地址空間中去。
動態(tài)庫是可以被多個 app的進程共用的，所以在內(nèi)存中只會存在一份；如果是靜態(tài)庫，由于每個 app的 Mach-O 文件中都會存在一份，則會存在多份。相對靜態(tài)庫，使用動態(tài)庫可以減少 app 占用的內(nèi)存大小。動態(tài)庫不能直接運行，而是需要通過系統(tǒng)的動態(tài)鏈接加載器dyld 進行加載到內(nèi)存后執(zhí)行。
dyld加載流程
我們在ViewController的load方法處加一個斷點，通過bt打印堆棧信息查看app啟動是從哪里開始的
我們可以看到dyld是從_dyld_start方法開始的，所以我們?nèi)yld的源碼中一探究竟。
我們在源碼中搜索_dyld_start。在 dyldStartup.s 文件中找到了入口，這里是用匯編實現(xiàn)的，盡管在不同架構(gòu)下有所區(qū)別，但都是會調(diào)用 dyldbootstrap 命名空間下的start方法，這和上面的堆棧順序也是相同的，這里我們以arm64架構(gòu)為例
這里的
call相當于bl跳轉(zhuǎn)指令的作用
dyldbootstrap::start
dyldbootstrap::start就是指 dyldbootstrap 這個命名空間作用域里的 start函數(shù)。
來到源碼中 , 搜索dyldbootstrap , 然后找到 start函數(shù)。
uintptr_t start(const dyld3::MachOLoaded* appsMachHeader, int argc, const char* argv[],
const dyld3::MachOLoaded* dyldsMachHeader, uintptr_t* startGlue)
{
...省略一些代碼
// now that we are done bootstrapping dyld, call dyld's main
uintptr_t appsSlide = appsMachHeader->getSlide();
return dyld::_main((macho_header*)appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}
可以看到其核心是返回值的調(diào)用了dyld的main函數(shù)
dyld::_main
main函數(shù)洋洋灑灑寫了600多行...，這里簡單的羅列一下其中都做了什么
uintptr_t
_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide,
int argc, const char* argv[], const char* envp[], const char* apple[],
uintptr_t* startGlue)
{
......省略部分代碼
// 設(shè)置運行環(huán)境，可執(zhí)行文件準備工作
......省略部分代碼
// load shared cache 加載共享緩存
mapSharedCache();
......省略部分代碼
reloadAllImages:
......省略部分代碼
// instantiate ImageLoader for main executable 加載可執(zhí)行文件并生成一個ImageLoader實例對象
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
......省略部分代碼
// load any inserted libraries 加載插入的動態(tài)庫
if ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib)
loadInsertedDylib(*lib);
}
// link main executable 鏈接主程序
link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
......省略部分代碼
// link any inserted libraries 鏈接所有插入的動態(tài)庫
if ( sInsertedDylibCount > 0 ) {
for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
ImageLoader* image = sAllImages[i+1];
link(image, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
image->setNeverUnloadRecursive();
}
if ( gLinkContext.allowInterposing ) {
// only INSERTED libraries can interpose
// register interposing info after all inserted libraries are bound so chaining works
for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
ImageLoader* image = sAllImages[i+1];
// 注冊符號插入
image->registerInterposing(gLinkContext);
}
}
}
......省略部分代碼
//弱符號綁定
sMainExecutable->weakBind(gLinkContext);
sMainExecutable->recursiveMakeDataReadOnly(gLinkContext);
......省略部分代碼
// run all initializers 執(zhí)行初始化方法
initializeMainExecutable();
// notify any montoring proccesses that this process is about to enter main()
notifyMonitoringDyldMain();
return result;
}
總結(jié)：
第一步： 設(shè)置運行環(huán)境，為可執(zhí)行文件的加載做準備工作
第二步： 映射共享緩存到當前進程的邏輯內(nèi)存空間
第三步： 實例化主程序
第四步： 加載插入的動態(tài)庫
第五步： 鏈接主程序
第六步： 鏈接插入的動態(tài)庫
第七步： 執(zhí)行弱符號綁定（weakBind）
第八步： 執(zhí)行初始化方法;
第九步： 查找程序入口并返回main( )
我們觀察LLDB 調(diào)試堆棧結(jié)果， 發(fā)現(xiàn)dyld::_main函數(shù)之后走的是 dyld::initializeMainExecutable函數(shù)，那么是怎么調(diào)到這一步的呢？
我們發(fā)現(xiàn)是sMainExecutable->instantiateFromLoadedImage-> instantiateFromLoadedImage，這樣一步步調(diào)的。
instantiateFromLoadedImage
static ImageLoaderMachO* instantiateFromLoadedImage(const macho_header* mh, uintptr_t slide, const char* path)
{
// try mach-o loader
if ( isCompatibleMachO((const uint8_t*)mh, path) ) {
ImageLoader* image = ImageLoaderMachO::instantiateMainExecutable(mh, slide, path, gLinkContext);
addImage(image);
return (ImageLoaderMachO*)image;
}
throw "main executable not a known format";
}
這里通過instantiateMainExecutable方法創(chuàng)建創(chuàng)建一個ImageLoader實例對象，isCompatibleMachO 是檢查Mach-O的subtype是否是當前cpu可以支持，內(nèi)核會映射到主可執(zhí)行文件中，我們需要為映射到主可執(zhí)行文件的文件，創(chuàng)建ImageLoader。
這個函數(shù)的主要目的：dyld 獲得控制權(quán)之前，內(nèi)核會映射到可執(zhí)行文件，這一步正是創(chuàng)建了可執(zhí)行文件的映射ImageLoader， 返回給我們的主程序 sMainExecutable， 加在了我們的鏡像 image 里面。
instantiateMainExecutable
ImageLoader* ImageLoaderMachO::instantiateMainExecutable(const macho_header* mh, uintptr_t slide, const char* path, const LinkContext& context)
{
//dyld::log("ImageLoader=%ld, ImageLoaderMachO=%ld, ImageLoaderMachOClassic=%ld, ImageLoaderMachOCompressed=%ld\n",
// sizeof(ImageLoader), sizeof(ImageLoaderMachO), sizeof(ImageLoaderMachOClassic), sizeof(ImageLoaderMachOCompressed));
bool compressed;
unsigned int segCount;
unsigned int libCount;
const linkedit_data_command* codeSigCmd;
const encryption_info_command* encryptCmd;
sniffLoadCommands(mh, path, false, &compressed, &segCount, &libCount, context, &codeSigCmd, &encryptCmd);
// instantiate concrete class based on content of load commands
if ( compressed )
return ImageLoaderMachOCompressed::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
else
#if SUPPORT_CLASSIC_MACHO
return ImageLoaderMachOClassic::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
#else
throw "missing LC_DYLD_INFO load command";
#endif
}
這里代碼主要是為Mach-O創(chuàng)建映像，返回一個ImageLoader類型的image對象，即主程序。其中sniffLoadCommands函數(shù)時獲取Mach-O類型文件的Load Command的相關(guān)信息，并對其進行各種校驗。
sniffLoadCommands
// determine if this mach-o file has classic or compressed LINKEDIT and number of segments it has
void ImageLoaderMachO::sniffLoadCommands(const macho_header* mh, const char* path, bool inCache, bool* compressed,
unsigned int* segCount, unsigned int* libCount, const LinkContext& context,
const linkedit_data_command** codeSigCmd,
const encryption_info_command** encryptCmd)
{
*compressed = false;
*segCount = 0;
*libCount = 0;
*codeSigCmd = NULL;
*encryptCmd = NULL;
......省略部分代碼
switch (cmd->cmd) {
case LC_DYLD_INFO:
case LC_DYLD_INFO_ONLY:
case LC_LOAD_DYLIB:
case LC_LOAD_WEAK_DYLIB:
case LC_REEXPORT_DYLIB:
case LC_LOAD_UPWARD_DYLIB
......省略部分代碼
}
這個函數(shù)就是根據(jù) Load Commands 來加載主程序 .
compressed -> 根據(jù)LC_DYLD_INFO_ONYL來決定 。
segCount 段命令數(shù)量 , 最大不能超過 255 個。
libCount依賴庫數(shù)量 ,LC_LOAD_DYLIB (Foundation / UIKit ..), 最大不能超過 4095 個。
codeSigCmd , 應(yīng)用簽名 。
encryptCmd , 應(yīng)用加密信息 , ( 我們俗稱的應(yīng)用加殼 , 我們非越獄環(huán)境重簽名都是需要砸過殼的應(yīng)用才能調(diào)試) 。
接下來我們通過LLDB打印的堆棧信息可以看到，下面會調(diào)用ImageLoader::runInitializers方法。這里是在dyld::_main函數(shù)的第八步初始化方法，進入initializeMainExecutable源碼
initializeMainExecutable
void initializeMainExecutable()
{
// record that we've reached this step
gLinkContext.startedInitializingMainExecutable = true;
// run initialzers for any inserted dylibs
ImageLoader::InitializerTimingList initializerTimes[allImagesCount()];
initializerTimes[0].count = 0;
const size_t rootCount = sImageRoots.size();
if ( rootCount > 1 ) {
for(size_t i=1; i < rootCount; ++i) {
sImageRoots[i]->runInitializers(gLinkContext, initializerTimes[0]);
}
}
// run initializers for main executable and everything it brings up
sMainExecutable->runInitializers(gLinkContext, initializerTimes[0]);
// register cxa_atexit() handler to run static terminators in all loaded images when this process exits
if ( gLibSystemHelpers != NULL )
(*gLibSystemHelpers->cxa_atexit)(&runAllStaticTerminators, NULL, NULL);
// dump info if requested
if ( sEnv.DYLD_PRINT_STATISTICS )
ImageLoader::printStatistics((unsigned int)allImagesCount(), initializerTimes[0]);
if ( sEnv.DYLD_PRINT_STATISTICS_DETAILS )
ImageLoaderMachO::printStatisticsDetails((unsigned int)allImagesCount(), initializerTimes[0]);
}
主要是循環(huán)遍歷，都會執(zhí)行runInitializers方法
runInitializers
void ImageLoader::runInitializers(const LinkContext& context, InitializerTimingList& timingInfo)
{
uint64_t t1 = mach_absolute_time();
mach_port_t thisThread = mach_thread_self();
ImageLoader::UninitedUpwards up;
up.count = 1;
up.imagesAndPaths[0] = { this, this->getPath() };
processInitializers(context, thisThread, timingInfo, up);
context.notifyBatch(dyld_image_state_initialized, false);
mach_port_deallocate(mach_task_self(), thisThread);
uint64_t t2 = mach_absolute_time();
fgTotalInitTime += (t2 - t1);
}
根據(jù) LLDB調(diào)試堆棧結(jié)果。我們知道接下來我們要進processInitializers函數(shù)
processInitializers
void ImageLoader::processInitializers(const LinkContext& context, mach_port_t thisThread,
InitializerTimingList& timingInfo, ImageLoader::UninitedUpwards& images)
{
uint32_t maxImageCount = context.imageCount()+2;
ImageLoader::UninitedUpwards upsBuffer[maxImageCount];
ImageLoader::UninitedUpwards& ups = upsBuffer[0];
ups.count = 0;
// Calling recursive init on all images in images list, building a new list of
// uninitialized upward dependencies.
for (uintptr_t i=0; i < images.count; ++i) {
images.imagesAndPaths[i].first->recursiveInitialization(context, thisThread, images.imagesAndPaths[i].second, timingInfo, ups);
}
// If any upward dependencies remain, init them.
if ( ups.count > 0 )
processInitializers(context, thisThread, timingInfo, ups);
}
同樣的根據(jù)LLDB 調(diào)試堆棧結(jié)果。我們知道接下來我們要進recursiveInitialization函數(shù)，發(fā)現(xiàn)點不進去recursiveInitialization，我們就全局搜索recursiveInitialization (
recursiveInitialization
void ImageLoader::recursiveInitialization(const LinkContext& context, mach_port_t this_thread, const char* pathToInitialize,
InitializerTimingList& timingInfo, UninitedUpwards& uninitUps)
{
recursive_lock lock_info(this_thread);
recursiveSpinLock(lock_info);
if ( fState < dyld_image_state_dependents_initialized-1 ) {
uint8_t oldState = fState;
// break cycles
fState = dyld_image_state_dependents_initialized-1;
try {
// initialize lower level libraries first
for(unsigned int i=0; i < libraryCount(); ++i) {
ImageLoader* dependentImage = libImage(i);
if ( dependentImage != NULL ) {
// don't try to initialize stuff "above" me yet
if ( libIsUpward(i) ) {
uninitUps.imagesAndPaths[uninitUps.count] = { dependentImage, libPath(i) };
uninitUps.count++;
}
else if ( dependentImage->fDepth >= fDepth ) {
dependentImage->recursiveInitialization(context, this_thread, libPath(i), timingInfo, uninitUps);
}
}
}
// record termination order
if ( this->needsTermination() )
context.terminationRecorder(this);
// let objc know we are about to initialize this image
uint64_t t1 = mach_absolute_time();
fState = dyld_image_state_dependents_initialized;
oldState = fState;
context.notifySingle(dyld_image_state_dependents_initialized, this, &timingInfo);
// initialize this image
bool hasInitializers = this->doInitialization(context);
// let anyone know we finished initializing this image
fState = dyld_image_state_initialized;
oldState = fState;
context.notifySingle(dyld_image_state_initialized, this, NULL);
if ( hasInitializers ) {
uint64_t t2 = mach_absolute_time();
timingInfo.addTime(this->getShortName(), t2-t1);
}
}
catch (const char* msg) {
// this image is not initialized
fState = oldState;
recursiveSpinUnLock();
throw;
}
}
recursiveSpinUnLock();
}
同樣的根據(jù)LLDB 調(diào)試堆棧結(jié)果。我們知道接下來我們要進notifySingle函數(shù)，發(fā)現(xiàn)點不進去notifySingle，我們就全局搜索notifySingle (
notifySingle
static void notifySingle(dyld_image_states state, const ImageLoader* image, ImageLoader::InitializerTimingList* timingInfo)
{
//dyld::log("notifySingle(state=%d, image=%s)\n", state, image->getPath());
std::vector<dyld_image_state_change_handler>* handlers = stateToHandlers(state, sSingleHandlers);
if ( handlers != NULL ) {
dyld_image_info info;
info.imageLoadAddress = image->machHeader();
info.imageFilePath = image->getRealPath();
info.imageFileModDate = image->lastModified();
for (std::vector<dyld_image_state_change_handler>::iterator it = handlers->begin(); it != handlers->end(); ++it) {
const char* result = (*it)(state, 1, &info);
if ( (result != NULL) && (state == dyld_image_state_mapped) ) {
//fprintf(stderr, " image rejected by handler=%p\n", *it);
// make copy of thrown string so that later catch clauses can free it
const char* str = strdup(result);
throw str;
}
}
}
if ( state == dyld_image_state_mapped ) {
// <rdar://problem/7008875> Save load addr + UUID for images from outside the shared cache
if ( !image->inSharedCache() ) {
dyld_uuid_info info;
if ( image->getUUID(info.imageUUID) ) {
info.imageLoadAddress = image->machHeader();
addNonSharedCacheImageUUID(info);
}
}
}
if ( (state == dyld_image_state_dependents_initialized) && (sNotifyObjCInit != NULL) && image->notifyObjC() ) {
uint64_t t0 = mach_absolute_time();
dyld3::ScopedTimer timer(DBG_DYLD_TIMING_OBJC_INIT, (uint64_t)image->machHeader(), 0, 0);
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
uint64_t t1 = mach_absolute_time();
uint64_t t2 = mach_absolute_time();
uint64_t timeInObjC = t1-t0;
uint64_t emptyTime = (t2-t1)*100;
if ( (timeInObjC > emptyTime) && (timingInfo != NULL) ) {
timingInfo->addTime(image->getShortName(), timeInObjC);
}
}
// mach message csdlc about dynamically unloaded images
if ( image->addFuncNotified() && (state == dyld_image_state_terminated) ) {
notifyKernel(*image, false);
const struct mach_header* loadAddress[] = { image->machHeader() };
const char* loadPath[] = { image->getPath() };
notifyMonitoringDyld(true, 1, loadAddress, loadPath);
}
}
接下來 LLDB調(diào)試堆棧就沒有了，分析可知其重點函數(shù)是(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());這句,我們來找一下 sNotifyObjCInit這個函數(shù)，發(fā)現(xiàn)它在registerObjCNotifiers這個函數(shù)里面
registerObjCNotifiers
void registerObjCNotifiers(_dyld_objc_notify_mapped mapped, _dyld_objc_notify_init init, _dyld_objc_notify_unmapped unmapped)
{
// record functions to call
sNotifyObjCMapped = mapped;
sNotifyObjCInit = init;
sNotifyObjCUnmapped = unmapped;
// call 'mapped' function with all images mapped so far
try {
notifyBatchPartial(dyld_image_state_bound, true, NULL, false, true);
}
catch (const char* msg) {
// ignore request to abort during registration
}
// <rdar://problem/32209809> call 'init' function on all images already init'ed (below libSystem)
for (std::vector<ImageLoader*>::iterator it=sAllImages.begin(); it != sAllImages.end(); it++) {
ImageLoader* image = *it;
if ( (image->getState() == dyld_image_state_initialized) && image->notifyObjC() ) {
dyld3::ScopedTimer timer(DBG_DYLD_TIMING_OBJC_INIT, (uint64_t)image->machHeader(), 0, 0);
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
}
}
}
搜索registerObjCNotifiers在哪里調(diào)用了，發(fā)現(xiàn)在_dyld_objc_notify_register進行了調(diào)用
void _dyld_objc_notify_register(_dyld_objc_notify_mapped mapped,
_dyld_objc_notify_init init,
_dyld_objc_notify_unmapped unmapped)
{
dyld::registerObjCNotifiers(mapped, init, unmapped);
}
接下來我們?nèi)ヌ剿?code>_dyld_objc_notify_register的源碼
注意：
_dyld_objc_notify_register的函數(shù)需要在libobjc源碼中搜索
_objc_init
void _objc_init(void)
{
static bool initialized = false;
if (initialized) return;
initialized = true;
// fixme defer initialization until an objc-using image is found?
environ_init();
tls_init();
static_init();
runtime_init();
exception_init();
cache_init();
_imp_implementationWithBlock_init();
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
#if __OBJC2__
didCallDyldNotifyRegister = true;
#endif
}
來到這里 , 我們就看到了 _dyld_objc_notify_register被調(diào)用 , 傳遞了三個參數(shù)
-
map_images: dyld 將image加載進內(nèi)存時 , 會觸發(fā)該函數(shù)。 -
load_images: dyld 初始化 image 會觸發(fā)該方法。( 我們所熟知的 load 方法也是在此處調(diào)用 ) -
unmap_image: dyld 將 image 移除時 , 會觸發(fā)該函數(shù)。也就是說_objc_init中注冊并保存了map_images , load_images , unmap_image函數(shù)地址。
走到這里我們還是沒有找到堆棧的閉環(huán)。怎么辦呢？
.....
我們回到 recursiveInitialization 當中的這行代碼查看doInitialization方法
doInitialization
根據(jù)LLDB調(diào)試堆棧我們就差 load images這一步了，很明顯，我們需要進入 doImageInit函數(shù)看看里面做了什么。
bool ImageLoaderMachO::doInitialization(const LinkContext& context)
{
CRSetCrashLogMessage2(this->getPath());
// mach-o has -init and static initializers
doImageInit(context);
doModInitFunctions(context);
CRSetCrashLogMessage2(NULL);
return (fHasDashInit || fHasInitializers);
}
我們進入到doImageInit的源碼中
doImageInit
void ImageLoaderMachO::doImageInit(const LinkContext& context)
{
if ( fHasDashInit ) {
const uint32_t cmd_count = ((macho_header*)fMachOData)->ncmds;
const struct load_command* const cmds = (struct load_command*)&fMachOData[sizeof(macho_header)];
const struct load_command* cmd = cmds;
for (uint32_t i = 0; i < cmd_count; ++i) {
switch (cmd->cmd) {
case LC_ROUTINES_COMMAND:
Initializer func = (Initializer)(((struct macho_routines_command*)cmd)->init_address + fSlide);
#if __has_feature(ptrauth_calls)
func = (Initializer)__builtin_ptrauth_sign_unauthenticated((void*)func, ptrauth_key_asia, 0);
#endif
// <rdar://problem/8543820&9228031> verify initializers are in image
if ( ! this->containsAddress(stripPointer((void*)func)) ) {
dyld::throwf("initializer function %p not in mapped image for %s\n", func, this->getPath());
}
if ( ! dyld::gProcessInfo->libSystemInitialized ) {
// <rdar://problem/17973316> libSystem initializer must run first
dyld::throwf("-init function in image (%s) that does not link with libSystem.dylib\n", this->getPath());
}
if ( context.verboseInit )
dyld::log("dyld: calling -init function %p in %s\n", func, this->getPath());
{
dyld3::ScopedTimer(DBG_DYLD_TIMING_STATIC_INITIALIZER, (uint64_t)fMachOData, (uint64_t)func, 0);
func(context.argc, context.argv, context.envp, context.apple, &context.programVars);
}
break;
}
cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
}
}
}
簡單分析一下這個函數(shù)，其實就是將函數(shù)方法的指針進行平移，最終找到其初始化的實現(xiàn)。
我們通過觀察注釋// <rdar://problem/17973316> libSystem initializer must run first 這里可以看到，這個函數(shù)第一次執(zhí)行 , 進行libsystem的初始化 . 會走到 doInitialization -> doModInitFunctions -> libSystemInitialized
libsystem 的初始化 , 它會調(diào)用起libdispatch_init, libdispatch 的 init 會調(diào)用_os_object_init , _os_object_init 這個函數(shù)里面調(diào)用了_objc_init
前面我們說過，_objc_init中注冊并保存了 map_images, load_images, unmap_image 函數(shù)地址，到這里終于 找到了load images調(diào)用的地方，LLDB調(diào)用堆棧的結(jié)果終于形成完整的閉環(huán)了!
