iOS底层原理探索--dyld加载流程分析

时间  2020-01-30
标签 ios 底层 原理 探索 dyld 加载 流程 分析 栏目 iOS 繁體版
原文   原文链接

iOS底层原理探索--dyld加载流程分析

参考文章：juejin.im/post/5e12ce…程序员

前言

在平时的开发过程当中，咱们经历过成千上万次的 Command + B/R 的过程，但可能不多有人关注这个过程当中 XCode 帮咱们作了哪些些事情。bootstrap

事实上，这个过程分解为4个步骤，分别是预处理(Prepressing)、编译(Compilation)、汇编(Assembly)和连接(Linking). ------ 摘自《程序员的自我修养-- 连接、装载与库》数组

在以上4个步骤中，IDE主要作了如下几件事:缓存

  1. 预编译：处理代码中的 # 开头的预编译指令，好比删除#define并展开宏定义，将#include包含的文件插入到该指令位置等；
  2. 编译：对预编译处理过的文件进行词法分析、语法分析和语义分析，并进行源代码优化，而后生成汇编代码；
  3. 汇编：经过汇编器将汇编代码转换为机器能够执行的指令，并生成目标文件.o文件；
  4. 连接：将目标文件连接成可执行文件。这一过程当中，连接器将不一样的目标文件连接起来，由于不一样的目标文件之间可能有相互引用的变量或调用的函数，如咱们常常调用 Foundation 框架和 UIKit 框架中的方法和变量，可是这些框架跟咱们的代码并不在一个目标文件中，这就须要连接器将它们与咱们本身的代码连接起来。

在苹果的操做系统中，就是由dyld来完成连接加载程序的操做。app

1、dyld简介

dyld(The dynamic link editor) 是苹果的动态连接器，负责程序的连接及加载工做，是苹果操做系统的重要组成部分。dyld是开源的，咱们能够在苹果的开源网站 OpenSource 上找到其源码。框架

点击去下载dyld源码dom

下载源码，咱们就能够分析dyld的加载过程了。ide

2、流程分析

首先咱们建立新的iOS工程，在ViewController的 .m 文件中实现一个空的 +load() 方法，并在该方法打断点 函数

函数调用栈
运行工程到此断点后，能够发现其函数调用栈以下：
经过这个函数调用栈，咱们发如今 +load() 方法以前还有一系列dyld的函数调用，咱们就以这些函数为线索来分析。

2.1 start函数分析

从函数调用栈咱们能够看见第一个调用的地方在dyld的 start 函数, 点击能够看见汇编代码以下post

咱们在dyld的源码里搜索 dyldbootstrap::start ，会发现有四个结果都在汇编代码里，因而咱们能够猜想start会不会是C语言的函数，搜索 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);
}
复制代码

在 start() 函数中主要作了一下几件事：

  1. 根据dyldsMachHeader计算出 slide, 经过slide断定是否须要重定位；这里的slide是根据 ASLR技术 计算出的一个随机值，使得程序每一次运行的偏移值都不同，防止攻击者经过固定地址发起恶意攻击；
slide = slideOfMainExecutable(dyldsMachHeader);
    bool shouldRebase = slide != 0;
#if __has_feature(ptrauth_calls)
    shouldRebase = true;
#endif
    if ( shouldRebase ) {
        rebaseDyld(dyldsMachHeader, slide);
    }
复制代码
  1. 初始化 mach_init() ，(allow dyld to use mach messaging，容许dyld使用mach消息传递)；
  2. 栈溢出保护
  3. 计算 appsMachHeader 的偏移，调用 dyld::_main() 函数。 由此咱们进入到了函数调用栈中 dyld::_main() 函数中。

2.2 dyld::_main()函数分析

点击进入 dyld::_main() 函数，代码以下

// Entry point for dyld. The kernel loads dyld and jumps to __dyld_start which
// sets up some registers and call this function.
//
// Returns address of main() in target program which __dyld_start jumps to
//
uintptr_t
_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide, 
		int argc, const char* argv[], const char* envp[], const char* apple[], 
		uintptr_t* startGlue)
{

}
复制代码

dyld::main()函数的代码比较多，这里只展现了方法名称和参数。dyld::main()主要作了如下几件事：

  1. setContext:
  2. 加载共享缓存
  3. reloadAllImages
  4. 加载插入的库（load any inserted libraries）
  5. 连接主程序和插入的库
  6. 初始化主程序，initializeMainExecutable();

2.2.1 设置上下文及配置环境变量

CRSetCrashLogMessage("dyld: launch started");
setContext(mainExecutableMH, argc, argv, envp, apple);
复制代码

在main函数的 launch started 处咱们能够发现 setContext() 方法，点进方法咱们咱们发现这一步就是设置上下文 gLinkContext ，点进 gLinkContext 咱们发现它是一个LinkContext类型变量

咱们再点进去LinkContext能够发现它是一个结构体,
这个结构体存储了 dyld 连接过程当中的上下文信息，包括加载哪一个MachO文件、imageCount、环境变量等信息。 

configureProcessRestrictions(mainExecutableMH);
checkEnvironmentVariables(envp);
复制代码

接下来要配置进程受限以及检测环境变量，这两步操做会影响到有些库是否会被加载。

2.2.2 加载共享缓存

咱们为何要加载共享缓存？共享缓存究竟是什么呢？举个例子，咱们开发过程当中会常常用到 UIKit 和 Foundation 框架，这些框架是放在哪里呢，怎样加载呢？若是每一个app在运行时都加载一次，显然会十分影响效率，也是一种不经济的方式。苹果为了解决这一问题，使用了共享缓存机制这一方式。对于系统动态库，在app用到某一动态库时就加载进内存，其余app用到该动态库时就没必要重复加载。

点击 mapSharedCache() 方法中的 loadDyldCache 方法能够发现，会有这一逻辑判断，代码以下。

bool loadDyldCache(const SharedCacheOptions& options, SharedCacheLoadInfo* results) {
    results->loadAddress        = 0;
    results->slide              = 0;
    results->errorMessage       = nullptr;

#if TARGET_IPHONE_SIMULATOR
    // simulator only supports mmap()ing cache privately into process
    return mapCachePrivate(options, results);
#else
    if ( options.forcePrivate ) {
        // mmap cache into this process only
        return mapCachePrivate(options, results);
    }
    else {
        // fast path: when cache is already mapped into shared region
        bool hasError = false;
        if ( reuseExistingCache(options, results) ) {
            hasError = (results->errorMessage != nullptr);
        } else {
            // slow path: this is first process to load cache
            hasError = mapCacheSystemWide(options, results);
        }
        return hasError;
    }
#endif
}
复制代码

在进行共享缓存的加载前，dyld会检测是否能够禁用共享缓存，代码以下，咱们能够发现iOS系统下没法禁用共享缓存。

static void checkSharedRegionDisable(const dyld3::MachOLoaded* mainExecutableMH, uintptr_t mainExecutableSlide) {
#if __MAC_OS_X_VERSION_MIN_REQUIRED
	// if main executable has segments that overlap the shared region,
	// then disable using the shared region
	if ( mainExecutableMH->intersectsRange(SHARED_REGION_BASE, SHARED_REGION_SIZE) ) {
		gLinkContext.sharedRegionMode = ImageLoader::kDontUseSharedRegion;
		if ( gLinkContext.verboseMapping )
			dyld::warn("disabling shared region because main executable overlaps\n");
	}
#if __i386__
	if ( !gLinkContext.allowEnvVarsPath ) {
		// <rdar://problem/15280847> use private or no shared region for suid processes
		gLinkContext.sharedRegionMode = ImageLoader::kUsePrivateSharedRegion;
	}
#endif
#endif
	// iOS cannot run without shared region
复制代码

2.2.3 reloadAllImages

在MachO文件的LoadCommands中的有一种类型叫 LC_LOAD_DYLIB ，这一类型标识的是程序所依赖的动态库，如图所示：

程序运行时能够经过LC_LOAD_DYLIB来加载动态库，dyld中经过 instantiateFromLoadedImage() 函数来读取相关信息，进行动态库的加载 

// The kernel maps in main executable before dyld gets control. We need to 
// make an ImageLoader* for the already mapped in main executable.
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";
}
复制代码

首先调用 isCompatibleMachO() 判断是否兼容此MachO文件, 主要是判断MachO文件的Magic number、cputype、cpusubtype等字段是否正确。

若是MachO文件格式不正确则抛出异常，不然执行 instantiateMainExecutable() 方法实例化主程序，并添加image到sAllImages数组中。咱们来看一下 instantiateMainExecutable() 函数 

// create image for main executable
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
}
复制代码

在该函数中有几个未初始化的变量 compressed、segCount、libCount、codeSigCmd、encryptCmd ，这几个变量的地址做为参数，在 sniffLoadCommands() 调用后发生改变。 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:
		if ( cmd->cmdsize != sizeof(dyld_info_command) )
			throw "malformed mach-o image: LC_DYLD_INFO size wrong";
		dyldInfoCmd = (struct dyld_info_command*)cmd;
		*compressed = true;
		break;
	case LC_SEGMENT_COMMAND:
		segCmd = (struct macho_segment_command*)cmd;
	case LC_SEGMENT_COMMAND:
		// ignore zero-sized segments
		if ( segCmd->vmsize != 0 ) *segCount += 1;
	case LC_LOAD_DYLIB:
	case LC_LOAD_WEAK_DYLIB:
	case LC_REEXPORT_DYLIB:
	case LC_LOAD_UPWARD_DYLIB:
		*libCount += 1;
		// fall thru
	case LC_CODE_SIGNATURE:
		......
		if ( *codeSigCmd != NULL )
		throw "malformed mach-o image: multiple LC_CODE_SIGNATURE load commands";
		*codeSigCmd = (struct linkedit_data_command*)cmd;
		break;
	case LC_ENCRYPTION_INFO:
		......
		if ( *encryptCmd != NULL )
		throw "malformed mach-o image: multiple LC_ENCRYPTION_INFO load commands";
		*encryptCmd = (encryption_info_command*)cmd;
		break;
复制代码

介于代码比较长，这里只展现了部分代码，不过咱们也能够看见该函数主要是读取了MachO文件的LoadCommands信息，并赋值给以前定义的变量。 这几个变量的含义以下：

  1. compressed：
  2. segCount: MachO文件中segment数量
  3. libCount: MachO文件中依赖的动态库的数量
  4. codeSigCmd: 签名信息
  5. encryptCmd: 加密信息，如cryptid等

2.2.4 加载插入的库

if	( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
	for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib) 
		loadInsertedDylib(*lib);
}
	// record count of inserted libraries so that a flat search will look at 
	// inserted libraries, then main, then others.
	sInsertedDylibCount = sAllImages.size()-1;
复制代码

根据 DYLD_INSERT_LIBRARIES 来断定是否加载插入的库，若是容许加载插入的库且有插入的库，则for循环执行 loadInsertedDylib() 函数加载动态库，若是不容许加载插入的库，则执行下面的操做。

2.2.5 连接主程序和插入的库

// link main executable
gLinkContext.linkingMainExecutable = true;
#if SUPPORT_ACCELERATE_TABLES
if ( mainExcutableAlreadyRebased ) {
// previous link() on main executable has already adjusted its internal pointers for ASLR
// work around that by rebasing by inverse amount
  sMainExecutable->rebase(gLinkContext, -mainExecutableSlide);
}--nExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
sMainExecutable->setNeverUnloadRecursive();
if ( sMainExecutable->forceFlat() ) {
  gLinkContext.bindFlat = true;
  gLinkContext.prebindUsage = ImageLoader::kUseNoPrebinding;
}

// link any inserted libraries
// do this after linking main executable so that any dylibs pulled in by inserted 
// dylibs (e.g. libSystem) will not be in front of dylibs the program uses
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);
   }
}
复制代码

经过 link() 函数连接主程序和插入的库，连接完毕后还会进行 recursiveBind() 、弱绑定 weakBind() 。至此，dyld进行setContext、加载共享缓存、reloadAllImages、加载插入的库、连接主程序和插入的库已完成，加下来会进行初始化主程序的操做。

2.2.6 initializeMainExecutable()

进行到这一步，咱们会发现正好对应文章开头的函数调用栈中第6步的 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]);
}
复制代码

从代码中咱们能够看到 runInitializers() 函数，由注释能够看到该函数是用来运行主程序初始化器的，并且该函数正对应函数调用栈中的第5步，从这一步开始方法的所在的类由dyld变成了ImageLoader。咱们进入函数中看一下代码：

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.images[0] = this;
	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);
}
复制代码

在该函数中咱们进一步能够看到函数调用栈第4步的 processInitializers() 函数，继续点进该函数咱们会发现，函数调用栈的第3步 recursiveInitialization() 函数，此时咱们没法再点进函数，可是能够经过在本文件中搜索的方式找到该函数。

在该函数中调用 doInitialization() 函数进行初始化后，会调用 LinkContext 的 notifySingle() 函数，到这里咱们发现该函数与函数调用栈的第2步的正好对应。接着函数调用栈的 load_images 函数，咱们在 notifySingle() 并无找到，并且在函数调用栈中也没有看到该函数在哪一个类中，个人理解是 notifySingle() 是一个通知回调函数，所以并不在dyld加载过程当中。其实这一部分属于objc调用流程中也会有，我将在探索类的加载时继续探索该部份内容。

3、总结

本篇文章主要总结了dyld的加载流程。将源代码转换为目标文件通常会经历 预编译、编译、汇编、连接的过程，dyld就是苹果的连接器，用于将可执行文件连接成目标文件，其主要流程有：

  • 1⃣️、设置上下文及配置环境变量
  • 2⃣️、加载共享缓存
  • 3⃣️、reloadAllImages
  • 4⃣️、加载插入的库
  • 5⃣️、连接主程序和插入的库
  • 6⃣️、初始化主程序

本文是第一次进行dyld底层探索，还有许多细节没有探索，欢迎你们批评指正，我会不断进行完善，后续也会继续进行底层的探索。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程