android so加载
本文分析so加载的步骤，其实在之前dalvik浅析二中也有提及，但那重点关注的是jni。android中so库的加载，代码如下：
loadLibrary("nanosleep");
我们来看下它的执行流程吧：
先调用dlopen来载入so文件；find_library在soinfo结构(进程加载的so链)中查找当前so是否已载入，否则去执行so载入流程。so载入后，find_library会返回soinfo，去执行so的CallConstructors函数；如果so包含init、init_array段，则此函数会先执行这init和init_array。dlopen函数执行完毕表示系统对so操作告一段落，接着通过dlsym获取地址去执行JNI_LOAD。对一般而言so的加载和执行到此为止了，下图是我们通常会关注到的执行流程：
普通而言就这样了，但这并不能满足我们的求知欲。下面以android4.4的linker代码来分析下后续的流程：
上面说到通过find_library函数来判断so是否已加载，而在该函数中实质是调用find_library_internal函数去实现全部功能的。来看下find_library_internal的执行流程，
在find_loaded_library中通过soinfo结构提取出so的name比较来进行判别so是否已加载。load_library函数分三步执行：1.打开so文件得到文件描述符；2.ElfReader(linker_phdr.h)结构体去加载(mmap)elfheader、elf_phdr、elf_segment;3.将ElfReader解析到的elf信息填充到soinfo结构体中。这里我们先看下load函数，究竟是load了哪些东东
bool ElfReader::Load(const android_dlextinfo* extinfo) { return ReadElfHeader() && //读取elf头到rc VerifyElfHeader() && //验证rc是否为elf头，主要是验证magic、type、version ReadProgramHeader() && //mmap映射segment 头 ReserveAddressSpace(extinfo) && // LoadSegments() && //映射load segment:代码段和数据段 FindPhdr(); //判断是否有PT_PHDR segment }
当然这里soinfo_link_image是重头戏：
phdr_table_get_dynamic_section函数得到.dynamic节区(注意这里是根据segment类型为PT_DYNAMIC来得到.dynamic section)，再通过.dynamic section解析出其他section；关于如何定位.dynamic节区和解析其他节区请参考elf文件格式(强烈建议在看本文之前观看)。不知各位看官注意到没有，对于载入so来说，只需segment就可以开工了(elf_shdr在这里没有用)。再来看so加载的重定位操作。
从rel节中取出elf32_rel并解析其type和elf32_sym，接着根据elf32_sym.name调用soinfo_do_lookup在其他so库(先前已加载)中找到对应的符号。soinfo_elf_lookup先将name hash并将此值作为hash表的索引得到funIndex，然后判断elf32_sym[funIndex].name是否相同。没说清楚，直接看源码吧
static Elf32_Sym* soinfo_elf_lookup(soinfo* si, unsigned hash, const char* name) { Elf32_Sym* symtab = si->symtab; const char* strtab = si->strtab; TRACE_TYPE(LOOKUP, "SEARCH %s in %s@0x%08x %08x %d", name, si->name, si->base, hash, hash % si->nbucket); for (unsigned n = si->bucket[hash % si->nbucket]; n != 0; n = si->chain[n]) { Elf32_Sym* s = symtab + n; if (strcmp(strtab + s->st_name, name)) continue; /* only concern ourselves with global and weak symbol definitions */ switch(ELF32_ST_BIND(s->st_info)){ case STB_GLOBAL: case STB_WEAK: if (s->st_shndx == SHN_UNDEF) { //SHN_UNDEF表示为外部调用，不是本so的函数，故还是没找到真正地址，继续找 continue; } TRACE_TYPE(LOOKUP, "FOUND %s in %s (%08x) %d", name, si->name, s->st_value, s->st_size); return s; } } return NULL; }
ok，从其他共享库中找到了对应的elf32_sym立刻保存其函数地址elf32_sym.st_value为sys_addr。然后根据type，将sys_addr处理后赋值给elf32_rel.r_offset所指向的值(这一步就是修改.got的值,.got保存着so外部调用符号的地址，类似于PE文件的IAT)。以上就是重定位的全部流程，就是帮外部调用找到其执行位置。
find_library就这样啦，来看看CallConstructors函数
void soinfo::CallConstructors() { if (constructors_called) { return; } if ((flags & FLAG_EXE) == 0 && preinit_array != NULL) { // The GNU dynamic linker silently ignores these, but we warn the developer. PRINT("\"%s\": ignoring %d-entry DT_PREINIT_ARRAY in shared library!", name, preinit_array_count); } if (dynamic != NULL) { for (Elf32_Dyn* d = dynamic; d->d_tag != DT_NULL; ++d) { if (d->d_tag == DT_NEEDED) { const char* library_name = strtab + d->d_un.d_val; TRACE("\"%s\": calling constructors in DT_NEEDED \"%s\"", name, library_name); find_loaded_library(library_name)->CallConstructors(); } } } TRACE("\"%s\": calling constructors", name); // DT_INIT should be called before DT_INIT_ARRAY if both are present. CallFunction("DT_INIT", init_func); CallArray("DT_INIT_ARRAY", init_array, init_array_count, false); } void soinfo::CallDestructors() { TRACE("\"%s\": calling destructors", name); // DT_FINI_ARRAY must be parsed in reverse order. CallArray("DT_FINI_ARRAY", fini_array, fini_array_count, true); // DT_FINI should be called after DT_FINI_ARRAY if both are present. CallFunction("DT_FINI", fini_func); }
CallConstructors里主要执行2个函数CallFunction、CallArray，即执行.init和.init_array节区的函数(可以在写so函数时指定在.init_array节)：
通过__attribute__((constructor(num)))声明某一函数(num 值越小， 越先执行 )， 即指定了在.init_array 中的位置， 修改其顺序即可实现。 例如：void __attribute__((constructor(101))) kingcoming(); ——by ThomasKing
CallDestructors在卸载so调用，也是执行2个函数与CallConstructors相对应的。值得一提的是constructors_called，它防止so的Constructors被重复调用，当前so有调用其他共享库的函数，则先执行其他共享库的Constructors。
dlopen完结了，而dlsym实质就是soinfo_elf_lookup来找到对应的函数。
参考资料:
