Android调试的必杀技——反汇编

核心提示：libjni_lib_test.so 0x6AC00000librunperf.so 0x6A800000libctest.so 0x6A700000libUAPI_jni.so 0x6A500000librpc.so 0x6A400000libtrace_test.so 0x6A300000libsrec_jni.s

libjni_lib_test.so 0x6AC00000

librunperf.so 0x6A800000

libctest.so 0x6A700000

libUAPI_jni.so 0x6A500000

librpc.so 0x6A400000

libtrace_test.so 0x6A300000

libsrec_jni.so 0x6A200000

libcerttool_jni.so 0x6A100000

libacc.so 0x6A000000

libbinder.so 0x69F00000

libskia.so 0x69000000

libGLES_android.so 0x68800000

libRS.so 0x68000000

libaudiopolicygeneric.so 0x67c00000

librs_jni.so 0x67800000

# Sigma Designs libraries

libcore.so 0x61400000

libdisplay.so 0x61000000

libdrm.so 0x60c00000

libhw.so 0x60800000

libplayback.so 0x60000000

从这个map文件我们可以查询到每个lib库的加载基地址。比如libc.so将会被内核加载到0x7EF00000，libsqlite.so加载到 0x7B100000。我们可以对照一下Crash的log信息也对应的上，说明这个文件在Android加载过程中起了作用。

下一步我们需要反汇编libc.so和libsqlite.so。一般交叉编译器都提供了反汇编的工具，我的mips平台提供了mips-linux-gnu-objdump命令来进行反汇编。

mips-linux-gnu-objdump -dS libc.so > libc.dump

mips-linux-gnu-objdump -dS libsqlite.so > libsqlite.dump

这样就可以得到libc和libsqlite的符号表。然后通过符号表，Android加载动态库的基地址，log信息就可以定位到那个函数出问题了，如果你对对应平台汇编语言熟悉的话可以阅读汇编代码找出问题。本文就不具体讲怎样利用这个三个文件信息了。有了这个三个文件，稍一研究就可以明白怎样分析了。

一般情况下，Crash都不是Android源码的问题，最有可能的是内核有些模块没有编译进去。本例中就是和Mutex相关的模块没有编译进内核引起的问题。

以上是个人摸索出来的方法，如果你有更好的方法或者我的方法有错误，请你不吝指教。