Android上可执行ELF文件中的段不能有基址
2016-04-06 00:00
381 查看
摘要: Android上可执行ELF文件中的段不能有基址
[TOC]
上面错误日志中有这么一行"#00 pc c0011c80 <unknown>"。依据Linux的知识，内存的低3G地址是用户空间高1G地址是内核空间，内核空间地址范围是0xc0000000~0xffffffff，也就是说此时的pc指向了内核内存范围，这肯定是有问题的。
观察上面的段信息可以发现，这些段都是有基址的，基址是0x60000000。段有基址，那么存在于段中的函数和变量也都是有基址的。
通过分析Android linker的源码发现，0xc0011c80地址值是linker对qemu-arm的构造函数进行重定位后的地址，该构造函数在ELF文件中显示的虚拟地址值是0x60011c80，0xc0011c80与0x60011c80之间差0x60000000，这里的0x60000000是linker将qemu-arm加载到内存时的基址。此时就不难理解0xc0011c80的值是怎么来的了，0xc0011c80等于"0x60000000 + 0x60011c80"，
下面是ndk-build编译出的可执行文件的段信息：
观察上面的段信息可以发现，通过ndk-build编译出来的可执行文件中的段是没有基址的。
0xc0011c80地址形成的印证
下面的代码摘自Android linker源码"android/system/bionic/linker/linker.cpp"文件（源自Android5.1.1源码）：
关于为什么编译qemu-arm可执行文件时输出ELF中的段有基址，可以阅读文章：编译可在Android上运行的qemu user mode中"添加arm的PIE支持"一节。
Android上可执行ELF文件中的段不能有基址
@(Android研究)[android][TOC]
场景
我使用Android NDK的编译工具交叉编译qemu项目（编译可在Android上运行的qemu user mode），将编译出来的qemu-arm可执行文件放到Android上执行时发生了"Segmentation fault"，通过分析错误日志（Android linker加载库失败时输出更详细调试信息），发现是linker加载qemu-arm时出错，简要错误日志见下：01-30 20:36:10.376 2078-2078/? A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xc0011c80 in tid 2078 (the_exe) 01-30 20:36:10.377 197-197/? I/DEBUG: property debug.db.uid not set; NOT waiting for gdb. 01-30 20:36:10.377 197-197/? I/DEBUG: HINT: adb shell setprop debug.db.uid 100000 01-30 20:36:10.377 197-197/? I/DEBUG: HINT: adb forward tcp:5039 tcp:5039 01-30 20:36:10.482 197-197/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 01-30 20:36:10.482 197-197/? I/DEBUG: Build fingerprint: 'google/hammerhead/hammerhead:5.1.1/LMY48M/2167285:user/release-keys' 01-30 20:36:10.482 197-197/? I/DEBUG: Revision: '11' 01-30 20:36:10.482 197-197/? I/DEBUG: ABI: 'arm' 01-30 20:36:10.483 197-197/? I/DEBUG: pid: 2078, tid: 2078, name: the_exe >>> ./the_exe <<< 01-30 20:36:10.483 197-197/? I/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc0011c80 01-30 20:36:10.491 26449-26682/system_process W/NativeCrashListener: Couldn't find ProcessRecord for pid 2078 01-30 20:36:10.558 197-197/? I/DEBUG: r0 00000000 r1 b6fa83bf r2 c0011c81 r3 b6fad714 01-30 20:36:10.558 197-197/? E/DEBUG: AM write failure (32 / Broken pipe) 01-30 20:36:10.558 197-197/? I/DEBUG: r4 c0011c80 r5 b6fa83bf r6 b6f9b004 r7 b6fa8486 01-30 20:36:10.558 197-197/? I/DEBUG: r8 00000010 r9 b6fad714 sl 00000001 fp 6011fdb8 01-30 20:36:10.558 197-197/? I/DEBUG: ip b6fa8486 sp bec6d7a8 lr b6f9f5b7 pc c0011c80 cpsr 800f0010 01-30 20:36:10.559 197-197/? I/DEBUG: #00 pc c0011c80 <unknown> 01-30 20:36:10.559 197-197/? I/DEBUG: #01 pc 000015b5 /system/bin/linker (__dl__ZN6soinfo12CallFunctionEPKcPFvvE+44) 01-30 20:36:10.559 197-197/? I/DEBUG: #02 pc 00001689 /system/bin/linker (__dl__ZN6soinfo9CallArrayEPKcPPFvvEjb+140) 01-30 20:36:10.559 197-197/? I/DEBUG: #03 pc 0000185f /system/bin/linker (__dl__ZN6soinfo16CallConstructorsEv+142) 01-30 20:36:10.559 197-197/? I/DEBUG: #04 pc 00003ae7 /system/bin/linker (__dl___linker_init+1594) 01-30 20:36:10.559 197-197/? I/DEBUG: #05 pc 00000a98 /system/bin/linker (_start+4) 01-30 20:36:10.559 197-197/? I/DEBUG: #06 pc 00000a98 /system/bin/linker (_start+4) 01-30 20:36:10.559 197-197/? I/DEBUG: #07 pc 00000a98 /system/bin/linker (_start+4) ......
上面错误日志中有这么一行"#00 pc c0011c80 <unknown>"。依据Linux的知识，内存的低3G地址是用户空间高1G地址是内核空间，内核空间地址范围是0xc0000000~0xffffffff，也就是说此时的pc指向了内核内存范围，这肯定是有问题的。
问题详解
下面是qemu-arm的段信息：Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 60000134 000134 000013 00 A 0 0 1 [ 2] .dynsym DYNSYM 60000148 000148 001b50 10 A 3 1 4 [ 3] .dynstr STRTAB 60001c98 001c98 0012d7 00 A 0 0 1 [ 4] .hash HASH 60002f70 002f70 000af8 04 A 2 0 4 [ 5] .gnu.version VERSYM 60003a68 003a68 00036a 02 A 2 0 2 [ 6] .gnu.version_r VERNEED 60003dd4 003dd4 000040 00 A 3 2 4 [ 7] .rel.dyn REL 60003e14 003e14 000050 08 A 2 0 4 [ 8] .rel.plt REL 60003e64 003e64 000d40 08 A 2 0 4 [ 9] .plt PROGBITS 60004ba4 004ba4 0013f4 00 AX 0 0 4 [10] .text PROGBITS 60005f98 005f98 0d3f00 00 AX 0 0 4 [11] .note.android.ide PROGBITS 600d9e98 0d9e98 000018 00 A 0 0 4 [12] .rodata PROGBITS 600d9eb0 0d9eb0 0236c4 00 A 0 0 8 [13] .ARM.extab PROGBITS 600fd574 0fd574 00003c 00 A 0 0 4 [14] .ARM.exidx ARM_EXIDX 600fd5b0 0fd5b0 0000b8 08 AL 10 0 4 [15] .data.rel.ro.loca PROGBITS 600fe690 0fd690 00b7e8 00 WA 0 0 8 [16] .fini_array FINI_ARRAY 60109e78 108e78 000008 00 WA 0 0 4 [17] .init_array INIT_ARRAY 60109e80 108e80 000040 00 WA 0 0 4 [18] .preinit_array PREINIT_ARRAY 60109ec0 108ec0 000008 00 WA 0 0 4 [19] .data.rel.ro PROGBITS 60109ec8 108ec8 004f30 00 WA 0 0 8 [20] .dynamic DYNAMIC 6010edf8 10ddf8 000128 08 WA 3 0 4 [21] .got PROGBITS 6010ef24 10df24 0010dc 00 WA 0 0 4 [22] .data PROGBITS 60110000 10f000 004164 00 WA 0 0 8 [23] .bss NOBITS 60114170 113170 10359f8 00 WA 0 0 16 [24] .comment PROGBITS 00000000 113164 000026 01 MS 0 0 1 [25] .debug_info PROGBITS 00000000 11318a 1efbce 00 0 0 1 [26] .debug_abbrev PROGBITS 00000000 302d58 01a79e 00 0 0 1 [27] .debug_loc PROGBITS 00000000 31d4f6 15fb92 00 0 0 1 [28] .debug_aranges PROGBITS 00000000 47d088 0010e8 00 0 0 8 [29] .debug_ranges PROGBITS 00000000 47e170 02c4e8 00 0 0 1 [30] .debug_line PROGBITS 00000000 4aa658 05d16e 00 0 0 1 [31] .debug_str PROGBITS 00000000 5077c6 02d269 01 MS 0 0 1 [32] .debug_frame PROGBITS 00000000 534a30 019bac 00 0 0 4 [33] .note.gnu.gold-ve NOTE 00000000 54e5dc 00001c 00 0 0 4 [34] .ARM.attributes ARM_ATTRIBUTES 00000000 54e5f8 00002b 00 0 0 1 [35] .symtab SYMTAB 00000000 54e624 021dc0 10 36 5874 4 [36] .strtab STRTAB 00000000 5703e4 015378 00 0 0 1 [37] .shstrtab STRTAB 00000000 58575c 000195 00 0 0 1
观察上面的段信息可以发现，这些段都是有基址的，基址是0x60000000。段有基址，那么存在于段中的函数和变量也都是有基址的。
通过分析Android linker的源码发现，0xc0011c80地址值是linker对qemu-arm的构造函数进行重定位后的地址，该构造函数在ELF文件中显示的虚拟地址值是0x60011c80，0xc0011c80与0x60011c80之间差0x60000000，这里的0x60000000是linker将qemu-arm加载到内存时的基址。此时就不难理解0xc0011c80的值是怎么来的了，0xc0011c80等于"0x60000000 + 0x60011c80"，
下面是ndk-build编译出的可执行文件的段信息：
Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 00000134 000134 000013 00 A 0 0 1 [ 2] .dynsym DYNSYM 00000148 000148 0000d0 10 A 3 1 4 [ 3] .dynstr STRTAB 00000218 000218 0000bf 00 A 0 0 1 [ 4] .hash HASH 000002d8 0002d8 000048 04 A 2 0 4 [ 5] .rel.dyn REL 00000320 000320 000060 08 A 2 0 4 [ 6] .rel.plt REL 00000380 000380 000040 08 AI 2 7 4 [ 7] .plt PROGBITS 000003c0 0003c0 000074 00 AX 0 0 4 [ 8] .text PROGBITS 00000434 000434 001608 00 AX 0 0 4 [ 9] .note.android.ide PROGBITS 00001a3c 001a3c 000018 00 A 0 0 4 [10] .ARM.exidx ARM_EXIDX 00001a54 001a54 000110 08 AL 8 0 4 [11] .rodata PROGBITS 00001b64 001b64 000016 01 AMS 0 0 1 [12] .ARM.extab PROGBITS 00001b7c 001b7c 00003c 00 A 0 0 4 [13] .fini_array FINI_ARRAY 00002e84 001e84 000008 00 WA 0 0 4 [14] .init_array INIT_ARRAY 00002e8c 001e8c 000010 00 WA 0 0 4 [15] .preinit_array PREINIT_ARRAY 00002e9c 001e9c 000008 00 WA 0 0 4 [16] .dynamic DYNAMIC 00002ea4 001ea4 000100 08 WA 3 0 4 [17] .got PROGBITS 00002fa4 001fa4 00005c 00 WA 0 0 4 [18] .bss NOBITS 00003000 002000 000004 00 WA 0 0 4 [19] .comment PROGBITS 00000000 002000 000023 01 MS 0 0 1 [20] .note.gnu.gold-ve NOTE 00000000 002024 00001c 00 0 0 4 [21] .ARM.attributes ARM_ATTRIBUTES 00000000 002040 00002d 00 0 0 1 [22] .shstrtab STRTAB 00000000 00206d 0000dd 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific)
观察上面的段信息可以发现，通过ndk-build编译出来的可执行文件中的段是没有基址的。
0xc0011c80地址形成的印证
下面的代码摘自Android linker源码"android/system/bionic/linker/linker.cpp"文件（源自Android5.1.1源码）：
#if defined(__arm__)
case R_ARM_RELATIVE:
#elif defined(__i386__)
case R_386_RELATIVE:
#endif
count_relocation(kRelocRelative);
MARK(rel->r_offset);
if (sym) {
DL_ERR("odd RELATIVE form...");
return -1;
}
TRACE_TYPE(RELO, "[R_ARM_RELATIVE/R_386_RELATIVE] RELO RELATIVE %p <- +%p",
reinterpret_cast<void*>(reloc), reinterpret_cast<void*>(base));
*reinterpret_cast<ElfW(Addr)*>(reloc) += base;
break;*reinterpret_cast<ElfW(Addr)*>(reloc) += base;语句可知，被重定位函数的最终地址等于ELF文件中的虚拟地址加上内存基址。这条语句印证了上面对于0xc0011c80地址形成的分析，同时也印证了
Android上可执行ELF文件中的段不能有基址，如果段中有基址那么内存基址与ELF中虚拟地址相加后通常将会产生一个很大的数值。
关于为什么编译qemu-arm可执行文件时输出ELF中的段有基址，可以阅读文章：编译可在Android上运行的qemu user mode中"添加arm的PIE支持"一节。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 使用C++实现JNI接口需要注意的事项
- Android IPC进程间通讯机制
- Android Manifest 用法
- [转载]Activity中ConfigChanges属性的用法
- Android之获取手机上的图片和视频缩略图thumbnails
- Android之使用Http协议实现文件上传功能
- Android学习笔记（二九）：嵌入浏览器
- android string.xml文件中的整型和string型代替
- i-jetty环境搭配与编译
- android之定时器AlarmManager
- android wifi 无线调试
- Android Native 绘图方法
- Android java 与 javascript互访(相互调用)的方法例子
- android 代码实现控件之间的间距
- android FragmentPagerAdapter的“标准”配置
- Android"解决"onTouch和onClick的冲突问题
- android:installLocation简析
- android searchView的关闭事件
- SourceProvider.getJniDirectories