什么是Mach-O文件?
- Mach-O是Mach object的缩写,是Mac\iOS上用来存储程序、库的标准格式。
- 常见的Mach-O文件类型
Mach-O类型 | 示例文件 |
---|---|
MH_OBJECT | 目标文件(.o) 静态库文件(.a)注:静态库其实就是多个目标文件合并在一起 |
MH_EXECUTE | 可执行文件,存放App的所有源码信息,在.app/xx |
MH_DYLIB | 动态库文件.dylib 或者 .framework/xx |
MH_DYLINKER | 动态链接编辑器,也就是/usr/lib/dyld工具 |
MH_DSYM | 此文件中存储这二进制文件符号信息(.dSYM/Contents/Resources/DWARF/xx),在开发中,我们经常使用此文件来分析App的崩溃信息 |
dyld和Mach-O
- dyld是iOS中用来加载可执行文件、动态库的工具,其实它本身也是一个Mach-O文件。
什么是dyld?
- dyld 动态加载器(又叫做动态链接编辑器)
- dyld的源码可以点击此处下载
dyld的作用。
dyld可以用来加载以下三种类型的Mach-O文件
- MH_EXECUTE
- MH_DYLIB
- MH_BUNDLE
ios平台的编译过程
-
.h.m.cpp等文件
-->预编译
-->编译
-->汇编
-->链接.a .lib. so
-->可执行文件
动态库和静态库的区别
- 静态库:链接时会被完整的复制到可执行文件中,所以如果两个程序都用了某个静态库,那么每个二进制可执行文件里面其实都含有这份静态库的代码。
- 动态库: 链接时不复制,在程序启动后用动态加载,然后再符号绑定,所以理论上动态库只用存在一份,好多个程序都可以动态链接到这个动态库上面,达到了节省内存(不是磁盘是内存中只有一份动态库),还有另外一个好处,由于动态库并不绑定到可执行程序上,所以我们想升级这个动态库就很容易,windows和linux上面一般插件和模块机制都是这样实现的。
dyld加载应用程序做了什么
- 我们通过一个例子来分析,新建一个ios工程,在
ViewController
里面添加一个load
方法,再在main.m增加一个c++函数,打印顺序如下
+[ViewController load]
来了 : kcFunc
来了 : main
- 打印函数调用堆栈
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1
* frame #0: 0x000000010fae5d87 Arm64Methd`+[ViewController load](self=ViewController, _cmd="load") at ViewController.m:32:5
frame #1: 0x00007fff51402e4b libobjc.A.dylib`load_images + 1317
frame #2: 0x000000010faf2d79 dyld_sim`dyld::notifySingle(dyld_image_states, ImageLoader const*, ImageLoader::InitializerTimingList*) + 418
frame #3: 0x000000010faff990 dyld_sim`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 438
frame #4: 0x000000010fafe7a6 dyld_sim`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 188
frame #5: 0x000000010fafe846 dyld_sim`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 82
frame #6: 0x000000010faf308c dyld_sim`dyld::initializeMainExecutable() + 199
frame #7: 0x000000010faf70fc dyld_sim`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 3831
frame #8: 0x000000010faf21cd dyld_sim`start_sim + 122
frame #9: 0x0000000112f9f8cc dyld`dyld::useSimulatorDyld(int, macho_header const*, char const*, int, char const**, char const**, char const**, unsigned long*, unsigned long*) + 2308
frame #10: 0x0000000112f9d575 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 818
frame #11: 0x0000000112f98227 dyld`dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) + 453
frame #12: 0x0000000112f98025 dyld`_dyld_start + 37
-
通过上述堆栈及对应的dyld的源码可以得出dyld的执行流程如下
dyld加载流程 -
dyld_start是用汇编实现的,调用dyldbootstrap::start(c++实现)
__dyld_start:
......
// call dyldbootstrap::start(app_mh, argc, argv, dyld_mh, &startGlue)
bl __ZN13dyldbootstrap5startEPKN5dyld311MachOLoadedEiPPKcS3_Pm
......
- dyldbootstrap::start
uintptr_t start(const dyld3::MachOLoaded* appsMachHeader, int argc, const char* argv[],
const dyld3::MachOLoaded* dyldsMachHeader, uintptr_t* startGlue)
{
// Emit kdebug tracepoint to indicate dyld bootstrap has started <rdar://46878536>
dyld3::kdebug_trace_dyld_marker(DBG_DYLD_TIMING_BOOTSTRAP_START, 0, 0, 0, 0);
// if kernel had to slide dyld, we need to fix up load sensitive locations
// we have to do this before using any global variables
rebaseDyld(dyldsMachHeader); //苹果为了应用安全通过ASLR(地址空间随机布局)做了一些地址偏移处理,这一操作就是找到真正的地址
// 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(argc, argv, envp, apple);
#endif
// 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);
}
-
我们着重看下dyld::_main里面做了什么
dyld::_main - 我们主要研究第7步对应上图的流程
-
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]);
......
}
-
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);
}
-
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
方法
void ImageLoader::recursiveInitialization(const LinkContext& context, mach_port_t this_thread, const char* pathToInitialize,
InitializerTimingList& timingInfo, UninitedUpwards& uninitUps)
{
......
// 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);
......
}
- 第一个
notifySingle
写了回调函数(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
,当执行doInitialization
方法后会通过doModInitFunctions
里面一系列初始化到libobjc里_objc_init的_dyld_objc_notify_register(&map_images, load_images, unmap_image);
方法又回到dyld
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);
}
-
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());
}
}
}
-
在上述方法里面就有sNotifyObjCInit的赋值,也就是
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
的第二个参数load_images
,而&map_images
赋值给了sNotifyObjCMapped
并在下面的notifyBatchPartial
方法里面有执行。 -
回到开始执行顺序的问题,通过上文知道调用
image.pngload_images
的时候会方法级别的调用(*load_method)(cls, @selector(load));
,然后在doModInitFunctions
有执行一些c++函数func(context.argc, context.argv, context.envp, context.apple, &context.programVars);
,最后由notifyMonitoringDyldMain();
进入我们熟知的main()函数
-
总结,到这里我们的dyld就与objc关联起来了。
网友评论