1.回顾
在上一篇博文中介绍了动态库和静态库的区别，对dyld动态链接器做了初步的探索分析，本篇博文就进一步的对dyld的源码进行分析。
2. MachO
在上篇文章中，已经找到了dyld的入口了，但是在分析源码之前，还得补充点内容。
在iOS中
Mach-O（可执行文件)怎么获取呢？
2.1 macOS工程查看MachO
直接编译运行之后就可以得到Mach-O，就是下面这个黑不溜秋的东西。
2.2 iOS工程查看MachO
iOS工程的话就需要找到Products里面的.app文件
然后
Show in Finder找到文件所在位置
同样这个黑不溜秋的就是
MachO可执行文件
2.3 MachOView查看MachO结构
把这个MachO文件，拖拽到MachOView里面就可以查看MachO的结构。
Header头部，包含可以执行的CPU架构，比如x86,arm64Load commands加载命令，包含文件的组织架构和在虚拟内存中的布局方式Data，数据，包含load commands中需要的各个段(segment)的数据，每一个Segment都得大小是Page的整数倍。
3. dyld 源码分析
3.1 dyld::_main
dyld的入口main函数，好家伙！我直呼好家伙啊！近千行的代码！
这太长了，代码就不贴出来了，一贴出来，本篇博文基本就结束了，太TM长了😂。
- 弱水三千，我只取一瓢，
- 代码千行，我只看几行！
好诗好诗啊！哈哈😁
3.1.1 环境变量设置
从底层源码的注释也能知道，这里是
dyld的入口
//
// 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)
{
if (dyld3::kdebug_trace_dyld_enabled(DBG_DYLD_TIMING_LAUNCH_EXECUTABLE)) {
launchTraceID = dyld3::kdebug_trace_dyld_duration_start(DBG_DYLD_TIMING_LAUNCH_EXECUTABLE, (uint64_t)mainExecutableMH, 0, 0);
}
//Check and see if there are any kernel flags
dyld3::BootArgs::setFlags(hexToUInt64(_simple_getenv(apple, "dyld_flags"), nullptr));
#if __has_feature(ptrauth_calls)
// Check and see if kernel disabled JOP pointer signing (which lets us load plain arm64 binaries)
if ( const char* disableStr = _simple_getenv(apple, "ptrauth_disabled") ) {
if ( strcmp(disableStr, "1") == 0 )
sKeysDisabled = true;
}
else {
// needed until kernel passes ptrauth_disabled for arm64 main executables
if ( (mainExecutableMH->cpusubtype == CPU_SUBTYPE_ARM64_V8) || (mainExecutableMH->cpusubtype == CPU_SUBTYPE_ARM64_ALL) )
sKeysDisabled = true;
}
#endif
上面截取
main函数部分代码， 主要是if条件对各种环境变量设置的判断
3.1.2 平台信息设置
在所有镜像文件中设置平台
ID，以便于调试器可以判断进程类型。
注意：这里的image不是图像的意思，是指镜像
3.1.3 共享缓存
检查是否开启，以及
共享缓存是否映射到共享区域，这都是系统级别的，系统控制的，缓存是很宝贵的资源。
- mapSharedCache
if ( sJustBuildClosure )
sClosureMode = ClosureMode::On;
// load shared cache
checkSharedRegionDisable((dyld3::MachOLoaded*)mainExecutableMH, mainExecutableSlide);
if ( gLinkContext.sharedRegionMode != ImageLoader::kDontUseSharedRegion ) {
#if TARGET_OS_SIMULATOR
if ( sSharedCacheOverrideDir)
mapSharedCache(mainExecutableSlide);
#else
mapSharedCache(mainExecutableSlide);
#endif
太难了！这么上千行的代码一行一行的往下看，不说眼睛受不了，人都要疯了！（PS：痛苦)
那么博主，你有什么好的探索方式吗？
哎，巧了！靓仔！还真有哦！
反推，直接看最后一行代码。我们从结果反推，看看都是什么条件导致的最后return。
通过搜索在
main函数里面定位result，发现和sMainExecutable有关系。
CRSetCrashLogMessage(sLoadingCrashMessage);
// instantiate ImageLoader for main executable
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
gLinkContext.mainExecutable = sMainExecutable;
gLinkContext.mainExecutableCodeSigned = hasCodeSignatureLoadCommand(mainExecutableMH);
再搜索看看
sMainExecutable是什么关键的东西。
貌似找
sMainExecutable是找对了，在推导的时候，我们要明确我们的目标是要找什么？我们现在不就是要找images镜像嘛！所以就应该对link、bind、load这些词要敏感。
从上图中代码中的一些关键代码sInsertedDylibCount/weakBind /linkingMainExecutable这些也可以验证，我们找sMainExecutable是找对了。
3.1.4 link 链接
从代码中也可以发现，sMainExecutable是link链接的一个参数
// load any inserted libraries 加载任何插入的库
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;
// link main executable 链接main可执行文件
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);
}
#endif
link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
sMainExecutable->setNeverUnloadRecursive();
if ( sMainExecutable->forceFlat() ) {
gLinkContext.bindFlat = true;
gLinkContext.prebindUsage = ImageLoader::kUseNoPrebinding;
}
- 遍历
DYLD_INSERT_LIBRARIES环境变量，调用loadInsertedDylib加载动态库。 - 链接主程序
3.1.5 主程序main的入口
#if SUPPORT_OLD_CRT_INITIALIZATION
// Old way is to run initializers via a callback from crt1.o
if ( ! gRunInitializersOldWay )
initializeMainExecutable();
#else
// run all initializers
initializeMainExecutable();
#endif
// notify any montoring proccesses that this process is about to enter main()
notifyMonitoringDyldMain();
if (dyld3::kdebug_trace_dyld_enabled(DBG_DYLD_TIMING_LAUNCH_EXECUTABLE)) {
dyld3::kdebug_trace_dyld_duration_end(launchTraceID, DBG_DYLD_TIMING_LAUNCH_EXECUTABLE, 0, 0, 2);
}
ARIADNEDBG_CODE(220, 1);
#if TARGET_OS_OSX
if ( gLinkContext.driverKit ) {
result = (uintptr_t)sEntryOverride;
if ( result == 0 )
halt("no entry point registered");
*startGlue = (uintptr_t)gLibSystemHelpers->startGlueToCallExit;
}
else
#endif
{
// find entry point for main executable
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()
// main 可执行文件使用 LC_MAIN，我们需要使用 libdyld 中的 helper 来调用 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;
}
}
}
- 执行初始化方法
initializeMainExecutable -
notifyMonitoringDyldMain通知任何监控进程，此进程即将进入main() - 通过
if判断result寻找主程序的入口点 -
result != 0时：使用LC_MAIN，我们需要使用libdyld中的helper来调用main() -
result == 0： 使用LC_UNIXTHREAD，dyld需要让程序中的“start”为main()设置
3.2 initializeMainExecutable
3.2.1 runInitializers
拿到镜像文件的个数，循环开始对镜像进行初始化
// 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]);
初始化进行前期的相关准备
runInitializers -> processInitializers
3.2.2 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);
}
通过
recursiveInitialization递归初始化，下面是核心代码部分
3.2.3 recursiveInitialization
// 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);
3.2.4 notifySingle
由
recursiveInitialization可以找到notifySingle
- notifySingle重点代码
路径加载和镜像文件加载是重点
全局搜索
sNotifyObjCInit，发现是_dyld_objc_notify_init类型
3.2.5 objc_init和dyld的联系
在
registerObjCNotifiers方法的第二个参数赋值给了sNotifyObjCInit
全局搜索
registerObjCNotifiers看看哪里调用了
发现，在dyldAPIs.cpp文件中找到了registerObjCNotifiers调用
// _dyld_objc_notify_register
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看着好眼熟啊！似曾相识燕归来啊！
这不就是libobjc.dylib源码里面_objc_init方法调用了啊！如下图:
在调用
_dyld_objc_notify_register函数时，传入了三个参数(map_images的函数地址 、load_images函数unmap_image函数)
那么回到dyld源码的工程，registerObjCNotifiers里面是这样的
sNotifyObjCMapped = mapped = &map_images
sNotifyObjCInit = init = load_images
sNotifyObjCUnmapped = unmapped = unmap_image
到此也就发现，objc_init和dyld关联起来了
objc_init()向dyld中注册了三个函数，在dyld进行动静态库加载过程时，当特定环境满足的条件下，这三个函数会调用执行。
之前一直在
dyld的源码里面，现在我们回到_objc_init里面在进行正向的猜测探索。
在_objc_init函数里面打上断点,查看堆栈信息，发现_oc_object_init是在libdispatch的源码里面。
那么现在就去
libdispatch的源码里面看看
libdispatch的源码里面发现了_oc_object_init的调用是在libdispatch_init，那么libdispatch_init是由谁来发起的呢？
从堆栈信息发现，是libSystem_initializer
那么现在又得去
LibSystem源码里面看看，发现libdispatch_init确实调用了
那么
libSystem_initializer又是谁来发起的呢？
通过堆栈信息可以发现是doModInitFunctions。
doModInitFunctions又回到了dyld了，这就是反向推导到正向的验证过程。
doModInitFunctions 在 ImageLoaderMachO::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);
}
ImageLoader::recursiveInitialization里面又调用了doInitialization,递归初始化镜像文件
// 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);
总结一下：objc_init()调用流程如下：
_dyld_start --> dyldbootstrap::start --> dyld::_main --> dyld::initializeMainExecutable --> ImageLoader::runInitializers --> ImageLoader::processInitializers --> ImageLoader::recursiveInitialization --> doInitialization -->libSystem_initializer（libSystem.B.dylib） --> _os_object_init（libdispatch.dylib） --> _objc_init(libobjc.A.dylib)
_dyld_objc_notify_register里面的方法是在什么时候调用的呢？
3.3 map_images和load_images
3.3.1 map_images
回到
libObjc.dylib也就是objc的源码工程，在map_images和load_images的方法处分别打上断点，发现是先走到了map_images处，再控制台bt打印堆栈信息
map_images方法首先执行的，再查看运行堆栈，其流程为：_dyld_objc_notify_register --> registerObjCNotifiers --> notifyBatchPartial --> map_images，
从dyld源码中也可以验证，如下：
3.3.2 load_images
点击继续运行到
load_images断点处，再打印堆栈信息
由此可以知道
load_images调用时机：
_dyld_objc_notify_register --> registerObjCNotifiers --> load_images
3.4 main调用时机探索
在上一篇博文iOS底层探索之dyld(上)中，我们有一个测试案例，执行顺序是+ load --> c++ --> main函数
那么就去源码里面探索下，到底是怎么走到main函数的。
3.4.1 load方法调用过程
load_images(const char *path __unused, const struct mach_header *mh)
{
....省略代码....
// Discover load methods
{
mutex_locker_t lock2(runtimeLock);
prepare_load_methods((const headerType *)mh);
}
// Call +load methods (without runtimeLock - re-entrant)
call_load_methods();
}
这里对所有类的load方法prepare，那么进入prepare_load_methods方法，主要是对所有镜像的懒加载的类、分类prepare，说白了就是找load methods。
classref_t const *classlist =
_getObjc2NonlazyClassList(mhdr, &count);
for (i = 0; i < count; i++) {
schedule_class_load(remapClass(classlist[i]));
}
category_t * const *categorylist = _getObjc2NonlazyCategoryList(mhdr, &count);
schedule_class_load为 类 和任何未加载的superclasses类递归调度 +load
// Recursively schedule +load for cls and any un-+load-ed superclasses.
// cls must already be connected.
static void schedule_class_load(Class cls)
{
if (!cls) return;
ASSERT(cls->isRealized()); // _read_images should realize
if (cls->data()->flags & RW_LOADED) return;
// Ensure superclass-first ordering
schedule_class_load(cls->getSuperclass());
add_class_to_loadable_list(cls);
cls->setInfo(RW_LOADED);
}
add_class_to_loadable_list把所有的+load收集到一起，先是类，然后再是分类的。
/***********************************************************************
* add_class_to_loadable_list
* Class cls has just become connected. Schedule it for +load if
* it implements a +load method.
**********************************************************************/
void add_class_to_loadable_list(Class cls)
{
IMP method;
loadMethodLock.assertLocked();
method = cls->getLoadMethod();
if (!method) return; // Don't bother if cls has no +load method
if (PrintLoading) {
_objc_inform("LOAD: class '%s' scheduled for +load",
cls->nameForLogging());
}
if (loadable_classes_used == loadable_classes_allocated) {
loadable_classes_allocated = loadable_classes_allocated*2 + 16;
loadable_classes = (struct loadable_class *)
realloc(loadable_classes,
loadable_classes_allocated *
sizeof(struct loadable_class));
}
loadable_classes[loadable_classes_used].cls = cls;
loadable_classes[loadable_classes_used].method = method;
loadable_classes_used++;
}
递归获取方法收集在
loadable_classes[loadable_classes_used].method，是从通过getLoadMethod方法获取的。
/***********************************************************************
* objc_class::getLoadMethod
* fixme
* Called only from add_class_to_loadable_list.
* Locking: runtimeLock must be read- or write-locked by the caller.
**********************************************************************/
IMP
objc_class::getLoadMethod()
{
runtimeLock.assertLocked();
const method_list_t *mlist;
ASSERT(isRealized());
ASSERT(ISA()->isRealized());
ASSERT(!isMetaClass());
ASSERT(ISA()->isMetaClass());
mlist = ISA()->data()->ro()->baseMethods();
if (mlist) {
for (const auto& meth : *mlist) {
const char *name = sel_cname(meth.name());
if (0 == strcmp(name, "load")) {
return meth.imp(false);
}
}
}
return nil;
}
递归所有的
baseMethods()，通过strcmp匹配"load"，这就是load方法的调用过程
3.4.2 C++函数调用时机
在
C++函数开始处打上断点，然后再bt打印调用堆栈信息查看
从堆栈信息可知是按
doInitialization -->doModInitFunctions --> C++(JPFunc)调用顺序，然后我们回到dyld源码搜索doInitialization
在上面已经验证过了
notifySingle的里面的流程是load_images方法的调用最后再到load，所以上图也验证了load方法是在C++之前的调用的。
那么再根据堆栈的调用进入到
doModInitFunctions方法里面。
这个
doModInitFunctions里面就是对于macho_header的处理，包括Load commands和macho_segment_command，for循环遍历macho_section里面的函数指针，也就是包括了C++方法。
3.4.3 dyld如何到main.m函数
C++函数后，dyldbootstrap::start后，会寻找main函数。从堆栈可以知道是从dyld的_dyld_start开始
_dyld_start是汇编写的，从汇编可以知道main函数存在rax寄存器里面，最后会jmp跳转到rax执行main函数。
那么现在去工程代码里面验证一下。
通过代码的
汇编跟踪调试，也可以发现是和dyld源码里面的汇编执行是一模模一样样。
通过
register read打印寄存器信息也可以发现，rax里面存的就是main，最后通过register read rax读取rax验证了rax = main函数。这就是dyld到main的过程。
这就是dyld的探索分析过程，试问还有谁能，把这么复杂的东西，分析的这么有条有理，我这该死的无处安放的魅力啊！哈哈😁
4. 总结
dyld分析反推到正向验证notifySingle单个通知注入_dyld_objc_notify_register注册回调函数，下句柄，类似block，dyld里面实现了map_images、load_images、unmap_image之后回调给_objc_init就可以开始正常调用了。-
libSystem库是最先开始初始化调用的，在ImageLoaderMachO::doModInitFunctions和ImageLoaderMachO::doImageInit里面可以验证，因为objc的相关操作依赖系统，dyld也等系统相关库初始化完成，才对镜像进行初始化、映射等操作。
doModInitFunctions main 、+ load 、C++执行顺序是+ load --> c++ --> main函数最后奉上
dyld流程分析图
更多内容持续更新
🌹 喜欢就点个赞吧👍🌹
🌹 觉得学习到了的，可以来一波，收藏+关注，评论 + 转发，以免你下次找不到我😁🌹
🌹欢迎大家留言交流，批评指正，互相学习😁，提升自我🌹
