首先要确保你所使用的gdb和gdbserver是配对的，最好（或必须）是sdk内相同platform（api level）下的gdb和gdbserver。否则你使用的gdb可能与运行测试机上的gdbserver，因为协议不兼容，而不能正常调试。
gdb 连接后提示，"Argument to arithmetic operation not a number or boolean."
gdbserver 连接后提示，“Unable to get location for thread creation breakpoint: requested event is not supported."
这种情况下，gdb是没法正常使用的，你将会在后续的调试中，不同情况地收到”Remote 'g' packet reply is too long:"
因为这个问题可能会耗费掉了你不少的时间和注意力。这时候最好就是去将你使用的gdb配对的gdbserver从sdk放到测试机去使用。
在测试机中默认有一个远程调试服务程序/system/bin/gdbserver，如果有上面的情况出现，至少使用绝对路径下的你所安排的gdbserver。
参数传递方式：
在x86下，要清楚特殊的传参行为。android的x86 gcc对静态函数的传参规则是，前面两个参数分别应用%eax和%edx，第三个参数开始应用参数栈。而this指针不是我们熟知的vc下应用ecx，gun gcc应用%ebx，而ndk是应用%eax。
下面回到百度加固平台的libbaiduprotect.so逆向。
libbaiduprotect_x86.so是对目标app的dex进行了加固，并且它自身也是加壳了的。下面是以加壳方式存储文件和脱壳后运行在内存映像的dump对比。
壳程序一般都安排在elf格式文件的.init_array section，由linker加载时最先执行。linker有这样的执行流程：
dl_open -> do_open -> soinfo::CallConstructors
只要通过中断linker的soinfo::CallConstructors方法，就可以将加载动态库之初使用程序中断。
中断后，我们通过%eax查看this指针的对象内容，soinfo::CallConstructors是成员方法，指针的对象类型是soinfo，这个结构体包含了加载后section信息。
这个结构的第一个结构成员是不同gcc平台下的linker都一样的，so文件名，查看结果与我调试加载的库名一致，libbaiduproctect_x86.so。后面的结构组织，不同版本的linker各不相同。在这里我懒得去配对正确的版本代码，也就不去搞清它的结构。但是可以通过运行时映射信息，以及readelf查看到的section信息，清楚看到.init_array和.fini_array的section信息加载到soinfo结构了。.init_array section一共0x14字节加载在0xadfa5464。
本例中so映射在0xadf16000，.text段偏移0x2bc0，也就说在0xadf8bc0。而JNI_OnLoad函数偏移量是0x3060，位于0xadf19060。
不用翻查代码，通过查看.init_array段0x14字节的内容，可以大至清楚这个段约等同一个函数指针数组，以空指针结尾。第一个函数指针位于.text的末端，后面三个函数指针位于.text段的开端。linker将按顺序去执行这四个函数。也就是说脱壳程序的其中一个入口就在这四个函数中。
现在我们的程序中断在soinfo::CallConstructors的入口，还没有执行so文件中任何的程序，我们如果反汇编JNI_OnLoad地址的话，就只能得到无法解释的加壳内容。
而so文件.init_array段的函数指针指向的函数则是怎么也就能是加壳的，或者至少保证前面的一个函数可以被执行脱壳出后面的函数。一般地，程序在对代码段进行脱壳，都必须要修改该段的内存访问属性，从只读变为可写才能将脱壳后的代码更新上去，也就说我们只要中断mprotect同样也会将脱壳程序中断到。
libbaiduprotect_x86.so并没有对所有.text段的代码进行脱壳，只是脱壳了一部分，并且在这阶段创建了6个线程，其中包含了反调试的监控线程。由于现在程序的运行被一步步掌控，所以可以将这些线程冻结然后进行后面的调试。
在这里我将被部分脱壳后的so映像dump出来，尝试用ida来静态分析，结果发现ida对x86指令支持并不好，一些原本在gdb能够反汇编的代码，不ida却识别不了。
