Android之调试共享库

Android C++调试

    Java代码出错的时候，我们会在第一时间想到调试。通过一番调试之后之后，问题就迎刃而解。我们现在很多项目中都会用到JNI调用，其中.so文件的c++代码出错了，什么办呢？

我们还是从一个简单的例子说起吧。现在.so文件有如下一个代码：

Jstring Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,jobject thiz ){ 

int *t;

*t = 1;

    return (*env)->NewStringUTF(env, "Hello from JNI !");

}

   分析上面代码: 由于指针t没有分配内存，所以给它赋值回报错. 接下来我们开始运行调用该so文件的Android项目，在Logcat下会发现如下错误信息:

    10-14 10:31:34.666: INFO/DEBUG(551): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

10-14 10:31:34.675: INFO/DEBUG(551): Build fingerprint: 'generic/sdk/generic/:1.5/CUPCAKE/147336:eng/test-keys'

10-14 10:31:34.675: INFO/DEBUG(551): pid: 6071, tid: 6071  >>> com.example.hellojni <<<

10-14 10:31:34.675: INFO/DEBUG(551): signal 7 (SIGBUS), fault addr 00000000

10-14 10:31:34.685: INFO/DEBUG(551):  r0 0000a9d0  r1 43736118  r2 41049d64  r3 00000001

10-14 10:31:34.685: INFO/DEBUG(551):  r4 befd8540  r5 00000004  r6 804002e5  r7 41049d3c

10-14 10:31:34.695: INFO/DEBUG(551):  r8 befd8520  r9 41049d34  10 41049d20  fp 00000000

10-14 10:31:34.695: INFO/DEBUG(551):  ip 804002e5  sp befd8510  lr ad00e3b8  pc 804002e4  cpsr 20000030

10-14 10:31:34.746: INFO/DEBUG(551):          #00  pc 000002e4  /data/data/com.example.hellojni/lib/libhello-jni.so

10-14 10:31:34.756: INFO/DEBUG(551):          #01  pc 0000e3b4  /system/lib/libdvm.so

10-14 10:31:34.765: INFO/DEBUG(551): stack:

    观察上面的日志文件，我们会发现c++代码调用的堆栈信息. 在最顶端堆栈的是libhello-jni.so（上面代码编译在此so文件里面），以及用红色标识出来的地址000002e4, 我们正是通过该地址找到出错的函数。

    ndk 提供了windows 对c++二进制分析的工具。最新已经是ndk1.6了，可以到网上很容易获得。其中arm-eabi-objump.exe 工具是可以用于分析so文件。如下所示:

    arm-eabi-objump.exe  –S  libhello-jni.so > test.txt 输出重定向到test.txt中。

    打开test.txt，我们看到如下信息:

    libhello-jni.so:     file format elf32-littlearm

Disassembly of section .text:

000002e4 <Java_com_example_hellojni_HelloJni_stringFromJNI>:

    2e4:    b510        push    {r4, lr}

    2e6:    2301        movs    r3, #1

    2e8:    601b        str r3, [r3, #0]

    2ea:    4905        ldr r1, [pc, #20]   (300 <.text+0x1c>)

    2ec:    6804        ldr r4, [r0, #0]

    2ee:    4a05        ldr r2, [pc, #20]   (304 <.text+0x20>)

    2f0:    23a7        movs    r3, #167

    2f2:    4479        add r1, pc

    2f4:    009b        lsls    r3, r3, #2

    2f6:    58e3        ldr r3, [r4, r3]

    2f8:    1889        adds    r1, r1, r2

    2fa:    4798        blx r3

    2fc:    bd10        pop {r4, pc}

    2fe:    0000        lsls    r0, r0, #0

    300:    10ae        asrs    r6, r5, #2

    302:    0000        lsls    r0, r0, #0

    304:    ef64 ffff   undefined

    我们可以看到红色的编译地址2e4. 和我们之前看到地址2e4一样。基本上可以定位是Java_com_example_hellojni_HelloJni_stringFromJNI函数的某一位置出错。仔细分析，可以定位到之前的问题。

 

接下来我还要介绍下面常用的二进制分析工具

AR 用来建立、修改、提取静态库文件.

NM 列出目标文件的符号表中定义的符号。常见的链接或者运行时发生的unresolved symbol类型的错误可以用NM来辅助调试

OBJDUMP  objdump是所有二进制工具之母，能够显示一个目标文件中所有的信息，通常我们用它来反汇编.text节中的二进制指令

READELF  readelf可用来显示ELF格式可执行文件的信息

SIZE

size命令可以列出目标文件每一段的大小以及总体的大小。默认情况下，对于每个目标文件或者一个归档文件中的每个模块只产生一行输出。size可以用来简单快速的了解ELF文件各个段的情况

ldd可用来显示执行文件需要哪些共享库, 共享库装载管理器在哪里找到了需要的共享库

 

工具的使用我这边就不想详细多说，网上对这些工具介绍有海量的信息。我想强调的是，要想深入解决c++的问题，我们要熟练掌握这些工具的使用，这对我们调试Android native code有非常大的帮助。

 

后面介绍些NDK的一些知识

 

1．  加载so 文件.

只要在项目工程上建立 如下目录结构：

在java代码中如下调用  System.loadlibrary(“ds”);  而不需要像我之前所说的要从Assert目录底下拷贝到应用程序目录下。

 

2．介绍Application.mk一些参数

APP_MODULES

这个变量必须有，用来描述你应用程序需要的所有原生模块(由Android.mk文件描述)，
这是用空格分割的模块名字列表，这个模块名字与在Android.mk文件中LOCAL_MODULE定义是一样的。

APP_PROJECT_PATH

这个变量必须有，应该给出你的程序项目的绝对路径，这是用于复制或安装剥离的共享库的版本到APK生成器所知道的位置。

APP_OPTIM
这个变量是可选的，可以定义成两个值'release' or 'debug'. 用于修改编译程序模块时的优化层级。

'release'模式是默认的，会产生高优化的文件，’debug’模式会生成不优化的文件，使得调试更容易进行。

主意，调试’release’和’debug’文件都是可能的，但是'release'版在调试节提高的信息很少，一些变量被优化输出，无法检查，代码被重排序，使得跟踪代码很困难，堆栈追踪也不可靠，等等…

APP_CFLAGS
一套编译器选项，在编译模块中的C代码时选用。这可能用于根据应用程序来改变模块的生成，以代替修改Android.mk文件本身。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wukunting/archive/2009/10/28/4740012.aspx