9.3.10灰度阶段收到大量Android 5.1设备崩溃，被秋实大佬@薛秋实拉入相关调查群，报错如下：
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/data/com.kuaishou.nebula/app_lib/libwesteros.so
看报错是System.load加载拍摄sdk的so westeros时失败了，具体的错误是"_Unwind_Resume"符号查找失败了。
P.S.：虚拟机加载so的更多源码细节，请参考附录1。
此类问题，根据过往的问题排查经验，推测是ndk工具链不统一导致的ABI兼容性bug，立即让拍摄sdk同学@王文峰查看一下westeros的编译工具链版本有无发生变化：
readelf libwesteros.so --string-dump=.note.android.ident
显示最近几个版本没变化，都是ndk r20：
String dump of section ‘.note.android.ident‘:
[ c] Android
[ 18] r20
[ 58] 5594570
于是又让拍摄同学看了一下westeros的符号依赖有没有变化：
readelf -s libwesteros.so | grep _Unwind_Resume
依然没有变化，都是：
0000000000000000 0 FUNC GLOBAL DEFAULT UND _Unwind_Resume
UND代表undefined，最近几个版本都是UND，问题可能出现在了westeros动态依赖的库上，首先怀疑的是“惯犯”libc++。因为不同的ndk版本，会对应不同版本的libc++_shared.so，libc++的ABI并不稳定，不一致时也会导致一些ABI兼容问题，于是解压查看主站apk里最近两个版本的libc++，却发现仍然没有变化，都是：
String dump of section ‘.note.android.ident‘:
[ c] Android
[ 18] r20
[ 58] 5594570
而且，此版本的libc++并不存在_Unwind_Resume符号。
问题复杂了起来，看来并不是简单的westeros切换了编译环境导致的问题，灰度版本不能delay。
这时，拍摄同学发现回退audioprocesslib能解决问题，测试同学发现32位没问题，只有64位才会崩。两个奇怪的现象，都不能从原理层面解释，只能先回退代码临时解决问题。
P.S.：ELF文件格式的更多信息请参考附录2
需要找到根因，首先研究一下_Unwind_resume的原理。
_Unwind_resume是用于处理c++异常的，已经被写入了C++ ABI规范。
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/lib/gcc/aarch64-linux-android/4.9.x/include/unwind.h 代码片段：
/* Resume propagation of an existing exception. This is used after
e.g. executing cleanup code, and not to implement rethrowing. */
extern void LIBGCC2_UNWIND_ATTRIBUTE
_Unwind_Resume (struct _Unwind_Exception *);
以ndk _Unwind_Resume为关键字搜索，很容易得到以下信息：
Common Issues
Unwinding
The NDK uses LLVM‘s libunwind. libunwind is needed to provide C++ exception handling support and C’s __attribute__((cleanup)). The unwinder is linked automatically by Clang, and is built with hidden visibility to avoid shared libraries re-exporting the unwind interface.
Until NDK r23, libgcc was the unwinder for all architectures other than 32-bit ARM, and even 32-bit ARM used libgcc to provide compiler runtime support. Libraries built with NDKs older than r23 by build systems that did not follow the advice in this document may re-export that incompatible unwinder. In this case those libraries can prevent the correct unwinder from being used by your build, resulting in crashes or incorrect behavior at runtime.
The best way to avoid this problem is to ensure all libraries in the application were built with NDK r23 or newer.
信息量挺大的，看上去像是个经典问题：
看上去都正常，而且ndk已经做了规避（不过比较扯的是建议大家都切换到ndk 23重新编一遍），那么问题出在哪呢？
ndk没有使用github作为代码托管工具进行持续集成开发，但是使用了github作为bug追踪反馈平台，仔细查阅过往的ndk issue，终于发现几条相关内容：
r21
$ for lib in /x/ndk-release-r21/out/android-ndk-r21/sources/cxx-stl/llvm-libc++/libs/*/libc++_shared.so; do printf ‘\n%s\n‘ $lib; readelf --dyn-syms -W $lib | grep ‘ _Unwind_Resume$‘; done
/x/ndk-release-r21/out/android-ndk-r21/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++_shared.so
1930: 00000000000b5e40 252 FUNC GLOBAL DEFAULT 11 _Unwind_Resume
/x/ndk-release-r21/out/android-ndk-r21/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++_shared.so
r20
$ for lib in /x/android-ndk-r20/sources/cxx-stl/llvm-libc++/libs/*/libc++_shared.so; do printf ‘\n%s\n‘ $lib; readelf --dyn-syms -W $lib | grep ‘ _Unwind_Resume$‘; done
/x/android-ndk-r20/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++_shared.so
/x/android-ndk-r20/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++_shared.so
上述第二个libc++_shared.so重复导出unwind符号导出的可怕之处，请看第三个“bug”：
The following link order will protect against incorrectly built dependencies:
可以看到静态库是建议优先于动态库的，但是让我们给link flags加上-Wl,-trace（跟宝哥@王连宝学的）看下实际上的默认link顺序（以koom为例）：
/llvm-sysroot/usr/lib/aarch64-linux-android/21/crtbegin_so.o
CMakeFiles/koom-java.dir/src/main/cpp/hprof_dump.cpp.o
/xxx-path/arm64-v8a/libxhook_lib.so
/xxx-path/arm64-v8a/libkwai-linker.so
/llvm-sysroot/usr/lib/aarch64-linux-android/21/liblog.so
/llvm-sysroot/usr/lib/aarch64-linux-android/21/libm.so
/xxx-path/arm64-v8a/libc++_shared.so
/llvm-sysroot/usr/lib/aarch64-linux-android/21/libm.so
/llvm-prebuilt/darwin-x86_64/lib/gcc/aarch64-linux-android/4.9.x/libgcc_real.a(unwind-dw2.o)
/llvm-prebuilt/darwin-x86_64/lib/gcc/aarch64-linux-android/4.9.x/libgcc_real.a(unwind-dw2-fde-dip.o)
/llvm-prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/21/libdl.so
/llvm-prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/21/libc.so
/llvm-prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/21/libdl.so
/llvm-prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/21/crtend_so.o
实际的顺序是：crtbegin > object files > 项目自身shared libraries > ndk 部分shared libraries > libgcc静态库 > crtend。这个顺序和建议的顺序完全不一样-_-||。
这个“bug”会导致，假设任意一个动态库重复导出了unwind符号，后续动态link依赖此so的库编译时，会优先选择此动态库里的unwind符号，这显然是不合理的，先不说稳定性、性能开销就变大了（plt调用多了一次跳转）。
貌似离真相很近了，但直接回答我们遇到的问题，还有些距离。
回顾下前面的两个现象：
先查看westeros的所有依赖库：
aarch64-linux-android-readelf libwesteros.so -d
Dynamic section at offset 0x123ed0 contains 39 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libprotobuf-lite.so]
0x0000000000000001 (NEEDED) Shared library: [libdaenerys.so]
0x0000000000000001 (NEEDED) Shared library: [libandroid.so]
0x0000000000000001 (NEEDED) Shared library: [liblog.so]
0x0000000000000001 (NEEDED) Shared library: [libEGL.so]
0x0000000000000001 (NEEDED) Shared library: [libjnigraphics.so]
0x0000000000000001 (NEEDED) Shared library: [libOpenSLES.so]
0x0000000000000001 (NEEDED) Shared library: [libGLESv2.so]
0x0000000000000001 (NEEDED) Shared library: [libffmpeg.so]
0x0000000000000001 (NEEDED) Shared library: [libz.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libc++_shared.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x000000000000000e (SONAME) Library soname: [libwesteros.so]
可以看出westeros并没有直接依赖audioprocesslib，于是依次排查每一个so和audioprocesslib的依赖情况以及unwind符号导出情况，终于发现问题出在了daenerys：
有问题的版本：
aarch64-linux-android-readelf libdaenerys.so -aW | grep _Un
000000000026ea48 000000ad00000402 R_AARCH64_JUMP_SLOT 0000000000000000 _Unwind_Resume + 0173: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _Unwind_Resume
正常的版本：
aarch64-linux-android-readelf libdaenerys.so -aW | grep _Unwind_R
0000000000272548 0000095e00000402 R_AARCH64_JUMP_SLOT 00000000001ca06c _Unwind_RaiseException + 0
0000000000272a00 000008c600000402 R_AARCH64_JUMP_SLOT 00000000001ca2d8 _Unwind_Resume + 02246: 00000000001ca2d8 252 FUNC GLOBAL DEFAULT 11 _Unwind_Resume
可以看到从正常到有问题，_Unwind_resume的Ndx(elf section index)从11变成了UND(undefined)。
实际上正是daenerys依赖了audioprocesslib，再去看audioprocesslib的_Unwind_resume符号依赖情况变化：果然，audioprocesslib的导出状态也发生了变化，旧版本的audioprocesslib是没有导出_Unwind_Resume的，但是新版本也就是有问题的版本变为了导出状态也就是.dynsym里搜索的结果是GLOBAL DEFAULT Ndx不是UND。
这时，一起定位的@陈翔宇同学也反馈发现audioprocesslib最近确实编译工具链从ndk r17升级了ndk版本到ndk r20，终于，所有的隐藏信息都齐了。
现在，我们基本可以推断出：首先ndk bug导致audioprocesslib升级工具链后audioprocesslib编译产物unwind符号导出状态变化，进而导致连锁反应daenerys的符号导出产生变化。
另外，雪上加霜的是，我发现虽然apk包里的daenerys是新版本，但是westeros动态link的是旧版本的daenerys。
然后，32位没问题的原因，参考ndk issue链接，32位没有使用libgcc.a，使用的libunwind.a始终是第一个link的；android高版本没问题的原因，是高版本系统库也意外导出了unwind符号，刚好可以查找的到。
这一系列阴差阳错的连锁反应，导致了前面所述的奇怪现象。
一图胜千言。--鲁迅
用一副图来总结这个bug的产生：
上图黑色代表原有逻辑，红色代表变更后引入bug的逻辑。
一个最稳妥的解决方案：和ndk官方的修复方案类似，在编译选项link flags里面加上-Wl,--exclude-libs,libgcc_real.a，手动排除libgcc的unwind相关符号的重复导出，就可以规避ndk的这个bug，还有减少符号导出带来的包大小和性能收益。
其他方案：修改link的顺序，保证libgcc静态库在动态库link的顺序前面。
随着工具链的升级普及，可能越来越多团队会类似甚至完全一样的问题，既有库一行代码不改只是重编了一下就会导致这个bug，难免会使得首次遇到这个问题时手忙脚乱，事实上这也是写这篇经验分享文章的理由之一。如前段时间在大群里看到的__aeabi_ldiv0的查找失败问题：
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__aeabi_ldiv0" referenced by "xxx.so"
Java虚拟机的JNI规范，以动态链接库即so的形式提供从java到native侧的调用，和传统Linux应用一样，动态库需要通过dlopen来动态加载，android java虚拟机so的加载如果以dlopen为界限的话，可以分为两个阶段，第一个阶段在虚拟机测由System.load发起，第二个阶段在dynamic linker侧由android_dlopen_ext发起（android_dlopen_ext是dlopen的android扩展实现，在原有的dlopen(3)上增加了一个const android_dlextinfo *__info参数）。额外提一句，当这两个过程完成后，虚拟机会使用dlsym查询so的JNI_OnLoad方法并调用。
以Android 11 Art虚拟机的so加载为例，分析具体源码。
最终调用：
void* handle = android_dlopen_ext(path, RTLD_NOW, &dlextinfo);
这一过程主要为虚拟机侧处理so的加载路径，调用方classloader对于的namespace权限，so重复加载判断等逻辑。且可以看到dlopen的flags传参为RTLD_NOW，代表所有未定义符号（UND symbol）都需要在加载阶段就被解析。
android和dynamic linker有关的文件有两个，libdl.so和/system/bin/linker(或/system/bin/linker64)，libdl只是一些的桩函数，实际的实现在linker，从dlopen调用开始的源码调用流程为：
我们这里关心的so加载的主要工作，就在find_library完成了so的装载(load)和链接(link)，按照随机（load会调用shuffle为了安全）的策略将DT_NEED间接依赖的so执行load，按照广度优先的策略将DT_NEED间接依赖的so执行link，具体单次某个so的load和link具体流程为：
//bionic/linker/linker_phdr.cpp
bool ElfReader::LoadSegments() {
for (size_t i = 0; i < phdr_num_; ++i) {
const ElfW(Phdr)* phdr = &phdr_table_[i];
if (phdr->p_type != PT_LOAD) {
continue;
}
// Segment addresses in memory.
ElfW(Addr) seg_start = phdr->p_vaddr + load_bias_;
ElfW(Addr) seg_end = seg_start + phdr->p_memsz;
ElfW(Addr) seg_page_start = PAGE_START(seg_start);
ElfW(Addr) seg_page_end = PAGE_END(seg_end);
ElfW(Addr) seg_file_end = seg_start + phdr->p_filesz;
// File offsets.
ElfW(Addr) file_start = phdr->p_offset;
ElfW(Addr) file_end = file_start + phdr->p_filesz;
ElfW(Addr) file_page_start = PAGE_START(file_start);
ElfW(Addr) file_length = file_end - file_page_start;
if (file_length != 0) {
int prot = PFLAGS_TO_PROT(phdr->p_flags);
if ((prot & (PROT_EXEC | PROT_WRITE)) == (PROT_EXEC | PROT_WRITE)) {
// W + E PT_LOAD segments are not allowed in O.if (get_application_target_sdk_version() >= 26) {
DL_ERR_AND_LOG("\"%s\": W+E load segments are not allowed", name_.c_str());
return false;
}
DL_WARN_documented_change(26,
"writable-and-executable-segments-enforced-for-api-level-26",
"\"%s\" has load segments that are both writable and executable",
name_.c_str());
add_dlwarning(name_.c_str(), "W+E load segments");
}
void* seg_addr = mmap64(reinterpret_cast<void*>(seg_page_start),
file_length,
prot,
MAP_FIXED|MAP_PRIVATE,
fd_,
file_offset_ + file_page_start);
...
}
...
}
...
}
//bionic/linker/linker_phdr.cpp
bool soinfo::prelink_image() {
...
/* Extract dynamic section */
ElfW(Word) dynamic_flags = 0;
phdr_table_get_dynamic_section(phdr, phnum, load_bias, &dynamic, &dynamic_flags);
...
for (ElfW(Dyn)* d = dynamic; d->d_tag != DT_NULL; ++d) {
...
switch (d->d_tag) {
...
case DT_HASH:
nbucket_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[0];
nchain_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[1];
bucket_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr + 8);
chain_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr + 8 + nbucket_ * 4);
break;
case DT_GNU_HASH:
gnu_nbucket_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[0];
// skip symndx
gnu_maskwords_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[2];
gnu_shift2_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[3];
gnu_bloom_filter_ = reinterpret_cast<ElfW(Addr)*>(load_bias + d->d_un.d_ptr + 16);
gnu_bucket_ = reinterpret_cast<uint32_t*>(gnu_bloom_filter_ + gnu_maskwords_);
// amend chain for symndx = header[1]
gnu_chain_ = gnu_bucket_ + gnu_nbucket_ -
reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[1];
...
--gnu_maskwords_;
flags_ |= FLAG_GNU_HASH;
break;
case DT_STRTAB:
strtab_ = reinterpret_cast<const char*>(load_bias + d->d_un.d_ptr);
break;
case DT_STRSZ:
strtab_size_ = d->d_un.d_val;
break;
case DT_SYMTAB:
symtab_ = reinterpret_cast<ElfW(Sym)*>(load_bias + d->d_un.d_ptr);
break;
...
}
...
}
...
}
重定位主要针对的是导入符号即调用的外部符号，这些符号在编译时的地址是未知的所以需要重定位，具体重定位的内容为附录2中的.rel.dyn和.rel.plt section中的符号，二者的区别为前者是数据的重定位，后者为函数调用的重定位，基本流程代码：
//bionic/linker/linker_relocate.cpp
bool soinfo::relocate(const SymbolLookupList& lookup_list) {
...
Relocator relocator(version_tracker, lookup_list);
...
if (relr_ != nullptr) {
DEBUG("[ relocating %s relr ]", get_realpath());
if (!relocate_relr()) {
return false;
}
}
#if defined(USE_RELA)if (rela_ != nullptr) {
DEBUG("[ relocating %s rela ]", get_realpath());
if (!plain_relocate<RelocMode::Typical>(relocator, rela_, rela_count_)) {
return false;
}
}
if (plt_rela_ != nullptr) {
DEBUG("[ relocating %s plt rela ]", get_realpath());
if (!plain_relocate<RelocMode::JumpTable>(relocator, plt_rela_, plt_rela_count_)) {
return false;
}
}
#elseif (rel_ != nullptr) {
DEBUG("[ relocating %s rel ]", get_realpath());
if (!plain_relocate<RelocMode::Typical>(relocator, rel_, rel_count_)) {
return false;
}
}
if (plt_rel_ != nullptr) {
DEBUG("[ relocating %s plt rel ]", get_realpath());
if (!plain_relocate<RelocMode::JumpTable>(relocator, plt_rel_, plt_rel_count_)) {
return false;
}
}
#endif
可以看到分别执行了.rel.dyn和.rel.plt的重定位，限于篇幅的原因，上述代码relocator的具体实现不再展开。大体原理为遍历每个重定位项，根据每个符号的字符串名称去依赖的so中查找此符号，查找成功后将地址修正为重定位后的地址，如查找失败即报错，本文这个案例，正是"_Unwind_resume"符号，没有在依赖的so中查找到。
ELF非常巧妙的一个地方在于，同一个ELF文件可以同时分为链接视图和执行视图来处理，分别的：
具体，如下图：
例如，查看westeros的链接视图section header：
aarch64-linux-android-readelf libwesteros.so -SW There are 26 section headers, starting at offset 0x145568: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .note.gnu.build-id NOTE 0000000000000200 000200 000024 00 A 0 0 4 [ 2] .hash HASH 0000000000000228 000228 0016fc 04 A 4 0 8 [ 3] .gnu.hash GNU_HASH 0000000000001928 001928 001448 00 A 4 0 8 [ 4] .dynsym DYNSYM 0000000000002d70 002d70 0058e0 18 A 5 3 8 [ 5] .dynstr STRTAB 0000000000008650 008650 00cbb3 00 A 0 0 1 [ 6] .gnu.version VERSYM 0000000000015204 015204 000768 02 A 4 0 2 [ 7] .gnu.version_r VERNEED 0000000000015970 015970 000040 00 A 5 2 8 [ 8] .rela.dyn RELA 00000000000159b0 0159b0 019ff8 18 A 4 0 8 [ 9] .rela.plt RELA 000000000002f9a8 02f9a8 002100 18 AI 4 21 8 [10] .plt PROGBITS 0000000000031ab0 031ab0 001620 10 AX 0 0 16 [11] .text PROGBITS 00000000000330d0 0330d0 09bcbc 00 AX 0 0 4 [12] .rodata PROGBITS 00000000000ced90 0ced90 022ede 00 A 0 0 16 [13] .eh_frame_hdr PROGBITS 00000000000f1c70 0f1c70 0061a4 00 A 0 0 4 [14] .eh_frame PROGBITS 00000000000f7e18 0f7e18 019930 00 A 0 0 8 [15] .gcc_except_table PROGBITS 0000000000111748 111748 008c78 00 A 0 0 4 [16] .note.android.ident NOTE 000000000011a3c0 11a3c0 000098 00 A 0 0 4 [17] .init_array INIT_ARRAY 000000000012a868 11a868 0000c0 08 WA 0 0 8 [18] .fini_array FINI_ARRAY 000000000012a928 11a928 000010 08 WA 0 0 8 [19] .data.rel.ro PROGBITS 000000000012a938 11a938 009598 00 WA 0 0 8 [20] .dynamic DYNAMIC 0000000000133ed0 123ed0 0002b0 10 WA 5 0 8 [21] .got PROGBITS 0000000000134180 124180 000e80 08 WA 0 0 8 [22] .data PROGBITS 0000000000135000 125000 020360 00 WA 0 0 8 [23] .bss NOBITS 0000000000155360 145360 001078 00 WA 0 0 16 [24] .comment PROGBITS 0000000000000000 145360 000108 01 MS 0 0 1 [25] .shstrtab STRTAB 0000000000000000 145468 0000fb 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), p (processor specific)
关键的section，如：.dynsym代表所有动态链接相关的（导入和导出）的符号，.rela.dyn和.rel.plt代表需要需要重定位的符号项，.got代表全局偏移表存储的是PIC(Position Independent Code)的符号与地址对照表，.plt也是为了实现PIC功能相关，存储的是导入符号即调用外部符号的对照表。
展开来看.dynsym（也是本文我们查找"_Unwind_Resume"符号时使用的命令）：
aarch64-linux-android-readelf libwesteros.so -sW
Symbol table ‘.dynsym‘ contains 948 entries:
Num: Value Size Type Bind Vis Ndx Name
12: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN6google8protobuf5Arena11AddListNodeEPvPFvS2_E
439: 00000000000a8290 16 FUNC GLOBAL DEFAULT 11 _ZN8kuaishou8westeros10VideoFrame16frame_number_keyEv
440: 00000000000acfc0 4 FUNC WEAK DEFAULT 11 _ZN8kuaishou8westeros8internal11PublishableINSt6__ndk110shared_ptrINS0_10VideoFrameEEEE16SetProcessorNameERKNS3_12basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEE
599: 00000000000ef600 44 OBJECT GLOBAL DEFAULT 12 _ZTSN8kuaishou8westeros21WesterosTextureDrawerE
这里选择了几个有代表性的符号，可以看到他们有以下几个不同点：
再来看执行视图：
aarch64-linux-android-readelf /Users/lirui/Downloads/nebula-GENERIC-gifmakerrelease-9.0.50.1014_x64/lib/arm64-v8a/libwesteros.so -lW
Elf file type is DYN (Shared object file)
Entry point 0x330d0
There are 8 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x11a458 0x11a458 R E 0x10000
LOAD 0x11a868 0x000000000012a868 0x000000000012a868 0x02aaf8 0x02bb70 RW 0x10000
DYNAMIC 0x123ed0 0x0000000000133ed0 0x0000000000133ed0 0x0002b0 0x0002b0 RW 0x8
NOTE 0x000200 0x0000000000000200 0x0000000000000200 0x000024 0x000024 R 0x4
NOTE 0x11a3c0 0x000000000011a3c0 0x000000000011a3c0 0x000098 0x000098 R 0x4
GNU_EH_FRAME 0x0f1c70 0x00000000000f1c70 0x00000000000f1c70 0x0061a4 0x0061a4 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
GNU_RELRO 0x11a868 0x000000000012a868 0x000000000012a868 0x00a798 0x00a798 R 0x1
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .plt .text .rodata .eh_frame_hdr .eh_frame .gcc_except_table .note.android.ident
01 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss
02 .dynamic
03 .note.gnu.build-id
04 .note.android.ident
05 .eh_frame_hdr
06
07 .init_array .fini_array .data.rel.ro .dynamic .got
可以看到segment的类型有LOAD、DYNAMIC、NOTE、GNU_EH_FRAME、GNU_STACK、GNU_RELRO几种，我们主要关注LOAD类型，附录1里so装载的过程有介绍segment通过mmap分配内存的细节。program header里还有segment和section的index对应关系。
ndk bug导致的cannot locate symbol "_Unwind_Reume"问题
原文：https://www.cnblogs.com/liunx1109/p/14743995.html