IOS底层原理之main函数之前-dyld的加载流程

作者: 风紧扯呼 | 来源:发表于2020-01-10 13:05 被阅读0次

一、前言

在iOS开发中，我们都存在这样的一个误区，那就是程序的入口在main函数，所有的程序运行由此函数的调用而开始运行，但是实际上在main函数之前会有一系列的工作在运行，比如+load方法和constructor构造函数就是在main函数之前执行的。这篇文章将从main函数入手向上探究main函数之前的程序内容。

二、从main函数出发

我们想知道在main函数之前程序的运行，那么我们可以在main函数上面断点查看函数调用栈的结果。

上面截图是在main函数上下断点后的函数调用栈，我们可以看出除了一个start函数的调用之外我们无法知道其他有用的信息，而且这个start函数是从哪里调用的我们根本无从得知道，这就比较尴尬了。那么如果我们在main函数之前执行的+load函数上下断点能否得到我们想要的答案呢。

如上图所示是在+load函数上下断点的函数调用栈，我们可以清晰的看到在+load函数之前执行的函数的调用情况。原来最开始的时候是从调用_dyld_start函数开始的。
_dyld_start是在libdyld.dylib库中的函数，这里下载到libdyld.dylib库的源码。本文是基于dyld-625.1版本进行分析的。

三、dyld加载流程

全局搜索_dyld_start，我们发现_dyld_start是在dyldStartup.s中的一段汇编代码，内部调用dyldbootstrap::start()方法，我们来看下dyldbootstrap::start()方法的源码。

1、dyldbootstrap::start()

uintptr_t start(const struct macho_header* appsMachHeader, int argc, const char* argv[], 
                intptr_t slide, const struct macho_header* dyldsMachHeader,
                uintptr_t* startGlue)
{
    // if kernel had to slide dyld, we need to fix up load sensitive locations
    // we have to do this before using any global variables
    slide = slideOfMainExecutable(dyldsMachHeader);
    bool shouldRebase = slide != 0;
#if __has_feature(ptrauth_calls)
    shouldRebase = true;
#endif
    if ( shouldRebase ) {
        rebaseDyld(dyldsMachHeader, slide);
    }

    // allow dyld to use mach messaging
    mach_init();

    // kernel sets up env pointer to be just past end of agv array
    const char** envp = &argv[argc+1];
    
    // kernel sets up apple pointer to be just past end of envp array
    const char** apple = envp;
    while(*apple != NULL) { ++apple; }
    ++apple;

    // set up random value for stack canary
    __guard_setup(apple);

#if DYLD_INITIALIZER_SUPPORT
    // run all C++ initializers inside dyld
    runDyldInitializers(dyldsMachHeader, slide, argc, argv, envp, apple);
#endif

    // now that we are done bootstrapping dyld, call dyld's main
    uintptr_t appsSlide = slideOfMainExecutable(appsMachHeader);
    return dyld::_main(appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}

这一段代码就是dyldbootstrap::start()方法的源码。从这段代码我们可以做了一下几步操作。

调用slideOfMainExecutable方法计算偏移地址(ALSR);

rebaseDyld进行了重定向；

mach_init方法初始化消息；

__guard_setup方法进行栈溢出保护；

代码的最后调用了一个_main函数,整个app启动的关键函数就是这个_main()函数.

2、_main函数

_main函数是一段又长又臭的代码，我们来注意分析下在这函数方里面的功能实现。

调用setContext方法设置上下文。
调用configureProcessRestrictions方法配置进程信息，主要是配置进程是否受限，默认是受限模式。
调用checkEnvironmentVariables方法检查环境变量。
调用getHostInfo方法从Mach-O头部获取当前运行架构的信息。
调用checkSharedRegionDisable方法检查是否开始共享缓存，在IOS中共享缓存是必须要开启的。然后调用mapSharedCache方法将共享缓存映射到缓存区域，在mapSharedCache函数方法内部会调用loadDyldCache方法进行加载缓存。
紧接着程序会走到reloadAllImages流程，这一步才是_main函数方法的重点内容，调用instantiateFromLoadedImage方法实例化主程序，这个方法实际上做了加载Mach-O文件的工作。

2.1、Mach-O文件

Mach-O其实是Mach Object文件格式的缩写，是mac以及iOS上可执行文件的格式，类似于windows上的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)。属于Mach-O格式的常见文件有:

目标文件.o 文件；
库文件.a文件、.dylib文件、Framework；
可执行文件；
.dsym文件；
dyld库；

一个完整的Mach-O文件分为:Header.LoadCommands.Data这三大部分，如下是Mach-O文件结构图。

Header 包含该二进制文件的一般信息，字节顺序、架构类型、加载指令的数量等。
Load commands 一张包含很多内容的表，内容包括区域的位置、符号表、动态符号表等。
Data 通常是对象文件中最大的部分，包含Segement的具体数据。

2.2、instantiateFromLoadedImage方法

instantiateFromLoadedImage方法加载了Mach-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";
}

在这段代码中，我们看到程序首先会判断Mach-O文件的合法性，如果合法则会调用instantiateMainExecutable方法生成返回一个ImageLoader对象，并通过addImage方法将得到的ImageLoader对象添加到imageList列表中去。

2.3、instantiateMainExecutable方法

下面是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
}

在这段代码中我们有看到sniffLoadCommands这样一个方法的调用，这个方法是用来加载Mach-O文件中的"Load commands"，并且修改了compressed这样一个变量，程序会根据这个变量的值来判断ImageLoaderMachOCompressed还是ImageLoaderMachOClassic中的instantiateMainExecutable方法创建ImageLoader对象返回，程序会在instantiateFromLoadedImage方法中将这个对象加载到imageList列表中去，至此就完成了主程序的实例化过程。

2.4 动态库插入

在主程序被实例化加载后,接下来dyld就会继续在 _main函数中去加载我们插入的动态库。

// load any inserted libraries
if( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
    for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib) 
        loadInsertedDylib(*lib);
}

这段代码遍历DYLD_INSERT_LIBRARIES环境变量，调用loadInsertedDylib方法加载，通过该环境变量我们可以注入自定义的一些动态库代码，loadInsertedDylib内部会从DYLD_ROOT_PATH、LD_LIBRARY_PATH、DYLD_FRAMEWORK_PATH等路径查找dylib并且检查代码签名，无效则直接抛出异常。

2.5 链接动态库

在加载完动态库之后，开始链接动态库，首先链接的是主程序，然后是插入的动态库。链接动态库是在link方法中进行的。

void ImageLoader::link(const LinkContext& context, bool forceLazysBound, bool preflightOnly, bool neverUnload, const RPathChain& loaderRPaths, const char* imagePath)
{
    //dyld::log("ImageLoader::link(%s) refCount=%d, neverUnload=%d\n", imagePath, fDlopenReferenceCount, fNeverUnload);
    
    // clear error strings
    (*context.setErrorStrings)(0, NULL, NULL, NULL);

    uint64_t t0 = mach_absolute_time();
    this->recursiveLoadLibraries(context, preflightOnly, loaderRPaths, imagePath);
    context.notifyBatch(dyld_image_state_dependents_mapped, preflightOnly);

    // we only do the loading step for preflights
    if ( preflightOnly )
        return;

    uint64_t t1 = mach_absolute_time();
    context.clearAllDepths();
    this->recursiveUpdateDepth(context.imageCount());

    __block uint64_t t2, t3, t4, t5;
    {
        dyld3::ScopedTimer(DBG_DYLD_TIMING_APPLY_FIXUPS, 0, 0, 0);
        t2 = mach_absolute_time();
        this->recursiveRebase(context);
        context.notifyBatch(dyld_image_state_rebased, false);

        t3 = mach_absolute_time();
        if ( !context.linkingMainExecutable )
            this->recursiveBindWithAccounting(context, forceLazysBound, neverUnload);

        t4 = mach_absolute_time();
        if ( !context.linkingMainExecutable )
            this->weakBind(context);//弱绑定
        t5 = mach_absolute_time();
    }

    if ( !context.linkingMainExecutable )
        context.notifyBatch(dyld_image_state_bound, false);
    uint64_t t6 = mach_absolute_time(); 

    std::vector<DOFInfo> dofs;
    this->recursiveGetDOFSections(context, dofs);
    context.registerDOFs(dofs);
    uint64_t t7 = mach_absolute_time(); 
...
}

在link方法中不光是链接主程序和插入动态库,还会在函数内通过recursiveLoadLibraries函数循环加载所有的依赖库。然后再Rebase每一个都添加上偏移值以后得到真正的依赖库的地址也就是重定位，然后对依赖库进行符号绑定,弱绑定等一系列操作,当这些都做完了主程序也就被加载链接完成。
和主程序链接加载一样，当有插入的动态库时，程序会对每一个插入的动态库进行链接加载。

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();
    }
    // 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);
    }
}

当所有的动态库的链接加载完成之后,就会调用initializeMainExecutable函数来初始化我们的主程序。

2.6 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]);
}

从这段代码我们可以看出来程序首先是对每一个插入进来的dylib调用runInitializers方法进行初始化，然后对主程序调用runInitializers方法初始化。runInitializers方法内部会调用processInitializers函数方法，而在processInitializers方法内部会调用recursiveInitialization方法，在recursiveInitialization函数方法内部我们找到和之前断点得到的函数调用栈一致的notifySingle方法。

2.7 notifySingle方法注册回调

在之前的函数调用栈中我们得知，在notifySingle方法之后调用的时候load_images方法，但是在notifySingle方法内部并未找到load_images方法，甚至是全局搜索也未找到load_images方法，但是在notifySingle方法内部有这样的一行代码。

(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());

我们猜想*sNotifyObjCInit这个函数指针有可能指向的是load_images方法，待load_images方法调用后在此执行回调，这个也符合程序的设计。全局搜索sNotifyObjCInit查看是在那里赋值的，不负所望在registerObjCNotifiers方法中找到了sNotifyObjCInit的赋值。

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
    }
      ...
}

查看registerObjCNotifiers方法的调用者，找到了_dyld_objc_notify_register方法，也就是这个方法的调用为sNotifyObjCInit的赋值来源。

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);
}

当再次对_dyld_objc_notify_register发起搜索时，并未能找到这个方法的调用者。由此我们可以直接下符号断点判断_dyld_objc_notify_register查看函数调用栈的结果。

从上面的截图函数的调用栈中可以看出来_dyld_objc_notify_register函数的调用是在_objc_init方法里面调用的。_objc_init方法是Objc源码中的一个方法，是runtime运行时的入口函数。

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();
    lock_init();
    exception_init();
    
    // _objc_init->map_images->map_images_nolock->_read_images->realizeClass
    _dyld_objc_notify_register(&map_images, load_images, unmap_image);
}

这段代码中我们看到在load_images的身影，这里的load_images就是前面在函数调用栈里面的load_images。在load_images里面会调用call_load_methods方法，我们来看下call_load_methods方法的代码。

do {
        // 1. Repeatedly call class +loads until there aren't any more
        while (loadable_classes_used > 0) {
            call_class_loads();
        }

        // 2. Call category +loads ONCE
        more_categories = call_category_loads();

        // 3. Run more +loads if there are classes OR more untried categories
    } while (loadable_classes_used > 0  ||  more_categories);

在这里的方法里面循环遍历所有的类并加载类里面的+load方法，然后会加载category中的+load方法。
让我们回到recursiveInitialization方法，在notifySingle之后程序会调用doInitialization方法。

2.8 doInitialization方法执行特殊函数

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);
}

在doInitialization内部会调用doModInitFunctions方法，这个函数会调用执行我们程序的特殊函数,比如全局的C++的构造方法.其实实质上就是dyld会读取Mach-O里DATA段中的init_func这个字段进行调用里面的函数。

2.9 进入main函数

最终一系列的操作完毕后，dyld就会去查找我们主程序的入口，对应我们Mach-O的LC_MAIN。在找到后返回一个result结果，也就调起了我们主程序的main函数，结束掉dyld_start整个流程。

result = (uintptr_t)sMainExecutable->getEntryFromLC_MAIN();
if ( result != 0 ) {
    // main executable uses LC_MAIN, we need to use helper in libdyld to call into main()
    if ( (gLibSystemHelpers != NULL) && (gLibSystemHelpers->version >= 9) )
        *startGlue = (uintptr_t)gLibSystemHelpers->startGlueToCallExit;
    else
        halt("libdyld.dylib support not present for LC_MAIN");
}
else {
    // main executable uses LC_UNIXTHREAD, dyld needs to let "start" in program set up for main()
    result = (uintptr_t)sMainExecutable->getEntryFromLC_UNIXTHREAD();
    *startGlue = 0;
}

到此整个dyld的加载流程就此完成。

IOS底层原理之main函数之前-dyld的加载流程

一、前言

二、从main函数出发

三、dyld加载流程

1、dyldbootstrap::start()

2、_main函数

2.1、Mach-O文件

2.2、instantiateFromLoadedImage方法

2.3、instantiateMainExecutable方法

2.4 动态库插入

2.5 链接动态库

2.6 initializeMainExecutable 初始化主程序

2.7 notifySingle方法注册回调

2.8 doInitialization方法执行特殊函数

2.9 进入main函数

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

源码解析