在移植Android过程中会遇到很多Crash的情况,尤其是启动Android过程中。一般这些问题都可以通过看代码能解决,当然也有一些比较“妖娆”的问题,非常难找到头绪,在logcat日志也只会打印一些崩溃的堆栈,这些信息很难帮助我们定位问题。根据个人一个实例来介绍一下在Android移植过程中反汇编的用法。
首先先看一下我遇到的一个logcat关于Crash的打印信息:
通过这个log信息我们可以看到libc.so崩溃了,再研究堆栈发现是libsqilte.so引起的,那么具体是哪一个函数崩溃了呢?这里面没有信息。另外内核加载动态库是动态加载的,就算我们反汇编出来libc.so和libsqlite.so,符号表也没有办法和log中地址对应上,除非我们能知道内核加载libc.so和libsqlite.so的基地址,这样我们就可以通过偏移找到相应的函数了。很幸运,Android确实规定了系统中的大部分库的内核加载地址。文件的位置在build/core下,有对应平台的map文件,比如:Arm平台文件名叫做prelink-linux-arm.map,Mips平台叫做prelink-linux-mips.map。我是在Mips平台出的问题,所以应该用prelink-linux-mips.map文件来定位。文件内容如下:
从这个map文件我们可以查询到每个lib库的加载基地址。比如libc.so将会被内核加载到0x7EF00000,libsqlite.so加载到0x7B100000。我们可以对照一下Crash的log信息也对应的上,说明这个文件在Android加载过程中起了作用。
下一步我们需要反汇编libc.so和libsqlite.so。一般交叉编译器都提供了反汇编的工具,我的mips平台提供了mips-linux-gnu-objdump命令来进行反汇编。
这样就可以得到libc和libsqlite的符号表。然后通过符号表,Android加载动态库的基地址,log信息就可以定位到那个函数出问题了,如果你对对应平台汇编语言熟悉的话可以阅读汇编代码找出问题。本文就不具体讲怎样利用这个三个文件信息了。有了这个三个文件,稍一研究就可以明白怎样分析了。
一般情况下,Crash都不是Android源码的问题,最有可能的是内核有些模块没有编译进去。本例中就是和Mutex相关的模块没有编译进内核引起的问题。
以上是个人摸索出来的方法,如果你有更好的方法或者我的方法有错误,请你不吝指教。
相关推荐
提高网络健壮性必杀技之——堆叠.doc
硬件工程师必杀技硬件工程师必杀技硬件工程师必杀技
通达信指标公式源码必杀技 一主二副 极品.doc
初中数学几何必杀技八大模型pdf
培训必杀技资料
KOF必杀技 泛型集合使用。演示图片的播放。
java乱码终极必杀技
2020QECon全球软件质量&效能大会,质量保障与管理专场张宏博先生做的今日头条服务端质量保障体系建设之战局规划与必杀技报告的PPT文档,分享给大家!
景观取名必杀技.doc
EXCEL25招必杀技,财务的人相当有用···
新人应对的必杀技.doc
硬件工程师必杀技,硬件工程师必备,硬件工程师要看
无线上等兵虚拟机必杀技
最全社会工程学之25篇必杀技
奢侈品牌的营销必杀技.pdf
撰写创业计划书必杀技.doc
奢侈品牌的营销必杀技.doc
【必杀技】爆杀单链表.cpp
开服装店销售技巧必杀技.doc
【政治】主观题答题必杀技