本文目录一览：
如何定位Android NDK开发中遇到的错误
NDK编译生成的.so文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。不同于Java代码异常造成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会立即退出，即通常所说的闪退，而不会弹出“程序xxx无响应，是否立即关闭”之类的提示框。
NDK是使用C/C++来进行开发的，熟悉C/C++的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题，最后都是同一个结果：程序崩溃。例如我们常说的空指针错误，就是当一个内存指针被置为空（NULL）之后再次对其进行访问；另外一个经常出现的错误是，在程序的某个位置释放了某个内存空间，而后在程序的其他位置试图访问该内存地址，这就会产生一个无效地址错误。常见的错误类型如下：
初始化错误
访问错误
数组索引访问越界
指针对象访问越界
访问空指针对象
访问无效指针对象
迭代器访问越界
内存泄露
参数错误
堆栈溢出
类型转换错误
数字除0错误
利用Android NDK开发本地应用的时候，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，首先生成一个错误，然后演示如何通过两种不同的方法，来定位错误的函数名和代码行。-objdumpwindows
首先，看我们在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），看下图：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中， std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。我们记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃。-objdumpwindows
下面来看看发生崩溃（闪退）时系统打印的logcat日志：
[plain] view plain copy
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'
pid: 32607, tid: 32607, name: xample.hellojni com.example.hellojni
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
r0 00000000 r1 beb123a8 r2 80808080 r3 00000000
r4 5d635f68 r5 5cdc3198 r6 41efcb18 r7 5d62df44
r8 4121b0c0 r9 00000001 sl 00000000 fp beb1238c
ip 5d635f7c sp beb12380 lr 5d62ddec pc 400e7438 cpsr 60000010
backtrace:
#00 pc 00023438 /system/lib/libc.so
#01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#05 pc 000505b9 /system/lib/libdvm.so
#06 pc 00068005 /system/lib/libdvm.so
#07 pc 000278a0 /system/lib/libdvm.so
#08 pc 0002b7fc /system/lib/libdvm.so
#09 pc 00060fe1 /system/lib/libdvm.so
#10 pc 0006100b /system/lib/libdvm.so
#11 pc 0006c6eb /system/lib/libdvm.so
#12 pc 00067a1f /system/lib/libdvm.so
#13 pc 000278a0 /system/lib/libdvm.so
#14 pc 0002b7fc /system/lib/libdvm.so
#15 pc 00061307 /system/lib/libdvm.so
#16 pc 0006912d /system/lib/libdvm.so
#17 pc 000278a0 /system/lib/libdvm.so
#18 pc 0002b7fc /system/lib/libdvm.so
#19 pc 00060fe1 /system/lib/libdvm.so
#20 pc 00049ff9 /system/lib/libdvm.so
#21 pc 0004d419 /system/lib/libandroid_runtime.so
#22 pc 0004e1bd /system/lib/libandroid_runtime.so
#23 pc 00001d37 /system/bin/app_process
#24 pc 0001bd98 /system/lib/libc.so
#25 pc 00001904 /system/bin/app_process
stack:
beb12340 012153f8
beb12344 00054290
beb12348 00000035
beb1234c beb123c0 [stack]
……
如果你看过logcat打印的NDK错误时的日志就会知道，我省略了后面很多的内容，很多人看到这么多密密麻麻的日志就已经头晕脑胀了，即使是很多资深的Android开发者，在面对NDK日志时也大都默默的选择了无视。-objdumpwindows
“符号化”NDK错误信息的方法
其实，只要你细心的查看，再配合Google 提供的工具，完全可以快速的准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对NDK错误进行符号化的工作，需要保留编译过程中产生的包含符号表的so文件，这些文件一般保存在$PROJECT_PATH/obj/local/目录下。-objdumpwindows
第一种方法：ndk-stack
这个命令行工具包含在NDK工具的安装目录，和ndk-build和其他一些常用的NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式-objdumpwindows
使用ndk-stack实时分析日志
在运行程序的同时，使用adb获取logcat日志，并通过管道符输出给ndk-stack，同时需要指定包含符号表的so文件位置；如果你的程序包含了多种CPU架构，在这里需求根据错误发生时的手机CPU类型，选择不同的CPU架构目录，如：-objdumpwindows
[plain] view plain copy
adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
当崩溃发生时，会得到如下的信息：
[plain] view plain copy
********** Crash dump: **********
Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'
pid: 32607, tid: 32607, name: xample.hellojni com.example.hellojni
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
Stack frame #00 pc 00023438 /system/lib/libc.so (strlen+72)
Stack frame #01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::char_traitschar::length(char const*)+20): Routine std::char_traitschar::length(char const*) at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229-objdumpwindows
Stack frame #02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const)+44): Routine basic_string at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639-objdumpwindows
Stack frame #03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69-objdumpwindows
Stack frame #04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61-objdumpwindows
Stack frame #05 pc 000505b9 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+516)-objdumpwindows
Stack frame #06 pc 00068005 /system/lib/libdvm.so
Stack frame #07 pc 000278a0 /system/lib/libdvm.so
Stack frame #08 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)-objdumpwindows
Stack frame #09 pc 00060fe1 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)-objdumpwindows
……（后面略）
我们重点看一下#03和#04，这两行都是在我们自己生成的libhello-jni.so中的报错信息，那么会发现如下关键信息：
[plain] view plain copy
#03 (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69
#04 (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61
回想一下我们的代码，在JNI_OnLoad()函数中（第61行），我们调用了willCrash()函数；在willCrash()函数中（第69行），我们制造了一个错误。这些信息都被准确无误的提取了出来！是不是非常简单？-objdumpwindows
先获取日志，再使用ndk-stack分析
这种方法其实和上面的方法没有什么大的区别，仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件，甚至可以在崩溃发生时，快速的将logcat日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。-objdumpwindows
[plain] view plain copy
adb shell logcat 1.log
ndk-stack -sym $PROJECT_PATH/obj/local/armeabi –dump 1.log
第二种方法：使用addr2line和objdump命令
这个方法适用于那些，不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但是可以满足一下程序员的好奇心。-objdumpwindows
先简单说一下这两个命令，在绝大部分的linux发行版本中都能找到他们，如果你的操作系统是linux，而你测试手机使用的是Intel x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。-objdumpwindows
别急，在NDK中自带了适用于各个操作系统和CPU架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，你可以在NDK目录的toolchains目录下找到他们。以我的Mac电脑为例，如果我要找的是适用于armeabi架构的工具，那么他们分别为arm-linux-androideabi-addr2line和arm-linux-androideabi-objdump；位置在下面目录中，后续介绍中将省略此位置：-objdumpwindows
[plain] view plain copy
/Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/-objdumpwindows
假设你的电脑是windows， CPU架构为mips，那么你要的工具可能包含在这个目录中：
[plain] view plain copy
D:\ android-ndk-r9d\toolchains\mipsel-linux-android-4.8\prebuilt\windows-x86_64\bin\
这个东西怎么用mingw5
mingw相当于windows下的gcc。用法和*nux下的gcc差不多，最常用到程序是gcc（编译器链主程序）,g++(c++编译器),gdb(调试器),objdump(一个很强的工具),然后一些不常用的ar（生成库文件）,as汇编器,cpp（预处理器）什么的。。。具体用法可以参照*nux下的gcc，命令基本一样。-objdumpwindows
例如有一份源代码a.c，编译的话可以调用：gcc -g -o a.exe a.cpp，-g表示带调试信息，-O?表示几级优化，-c表示只编译,-s表示只汇编，-I引用头文件，-L引用库文件，-x指定语言，然后调试的话,gdb a.exe载入程序，r运行，b设置断点，c继续，s单步,print,diaplay查看变量，q退出，什么的。。。-objdumpwindows
驱动如何调试
驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段，它们是：
1、利用printk
2、查看OOP消息
3、利用strace
4、利用内核内置的hacking选项
5、利用ioctl方法
6、利用/proc 文件系统
7、使用kgdb
前两种如下：
一、利用printk
这是驱动开发中最朴实无华，同时也是最常用和有效的手段。scull驱动的main.c第338行如下，就是使用printk进行调试的例子，这样的例子相信大家在阅读驱动源码时随处可见。
338 // printk(KERN_ALERT "wakeup by signal in process %d\n", current-pid);
printk的功能与我们经常在应用程序中使用的printf是一样的，不同之处在于printk可以在打印字符串前面加上内核定义的宏，例如上面例子中的KERN_ALERT（注意：宏与字符串之间没有逗号）。-objdumpwindows
#define KERN_EMERG "0"
#define KERN_ALERT "1"
#define KERN_CRIT "2"
#define KERN_ERR "3"
#define KERN_WARNING "4"
#define KERN_NOTICE "5"
#define KERN_INFO "6"
#define KERN_DEBUG "7"
#define DEFAULT_CONSOLE_LOGLEVEL 7
这个宏是用来定义需要打印的字符串的级别。值越小，级别越高。内核中有个参数用来控制是否将printk打印的字符串输出到控制台（屏幕或者/sys/log/syslog日志文件）
# cat /proc/sys/kernel/printk
6 4 1 7
第一个6表示级别高于（小于）6的消息才会被输出到控制台，第二个4表示如果调用printk时没有指定消息级别（宏）则消息的级别为4，第三个1表示接受的最高（最小）级别是1，第四个7表示系统启动时第一个6原来的初值是7。-objdumpwindows
因此，如果你发现在控制台上看不到你程序中某些printk的输出，请使用echo 8 /proc/sys/kernel/printk来解决。
在复杂驱动的开发过程中，为了调试会在源码中加入成百上千的printk语句。而当调试完毕形成最终产品的时候必然会将这些printk语句删除想想驱动的使用者而不是开发者吧。记住：己所不欲，勿施于人），这个工作量是不小的。最要命的是，如果我们将调试用的printk语句删除后，用户又报告驱动有bug，所以我们又不得不手工将这些上千条的printk语句再重新加上。oh，my god，杀了我吧。所以，我们需要一种能方便地打开和关闭调试信息的手段。哪里能找到这种手段呢？哈哈，远在天边，近在眼前。看看scull驱动或者leds驱动的源代码吧！-objdumpwindows
#define LEDS_DEBUG
#undef PDEBUG
#ifdef LEDS_DEBUG
#ifdef __KERNEL__
#define PDEBUG(fmt, args…) printk( KERN_EMERG "leds: " fmt, ## args)
#else
#define PDEBUG(fmt, args…) fprintf(stderr, fmt, ## args)
#endif
#else
#define PDEBUG(fmt, args…)
#endif
#undef PDEBUGG
#define PDEBUGG(fmt, args…)
这样一来，在开发驱动的过程中，如果想打印调试消息，我们就可以用PDEBUG("address of i_cdev is %p\n", inode-i_cdev);，如果不想看到该调试消息，就只需要简单的将PDEBUG改为PDEBUGG即可。而当我们调试完毕形成最终产品时，只需要简单地将第1行注释掉即可。-objdumpwindows
上边那一段代码中的__KERNEL__是内核中定义的宏，当我们编译内核（包括模块）时，它会被定义。当然如果你不明白代码中的…和##是什么意思的话，就请认真查阅一下gcc关于预处理部分的资料吧！如果你实在太懒不愿意去查阅的话，那就充当VC工程师把上面的代码copy到你的代码中去吧。-objdumpwindows
二、查看OOP消息
OOP意为惊讶。当你的驱动有问题，内核不惊讶才怪：嘿！小子，你干吗乱来！好吧，就让我们来看看内核是如何惊讶的。
根据faulty.c（单击下载）编译出faulty.ko，并 insmod faulty.ko。执行echo yang /dev/faulty，结果内核就惊讶了。内核为什么会惊讶呢？因为faulty驱动的write函数执行了*(int *)0 = 0，向内存0地址写入，这是内核绝对不会容许的。-objdumpwindows
52 ssize_t faulty_write (struct file *filp, const char __user *buf, size_t count,
53 loff_t *pos)
54 {
55
56 *(int *)0 = 0;
57 return 0;
58 }
1 Unable to handle kernel NULL pointer dereference at virtual address 00000000
2 pgd = c3894000
3 [00000000] *pgd=33830031, *pte=00000000, *ppte=00000000
4 Internal error: Oops: 817 [#1] PREEMPT
5 Modules linked in: faulty scull
6 CPU: 0 Not tainted (2.6.22.6 #4)
7 PC is at faulty_write+0×10/0×18 [faulty]
8 LR is at vfs_write+0xc4/0×148
9 pc : [] lr : [] psr: a0000013
10 sp : c3871f44 ip : c3871f54 fp : c3871f50
11 r10: 4021765c r9 : c3870000 r8 : 00000000
12 r7 : 00000004 r6 : c3871f78 r5 : 40016000 r4 : c38e5160
13 r3 : c3871f78 r2 : 00000004 r1 : 40016000 r0 : 00000000
14 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user
15 Control: c000717f Table: 33894000 DAC: 00000015
16 Process sh (pid: 745, stack limit = 0xc3870258)
17 Stack: (0xc3871f44 to 0xc3872000)
18 1f40: c3871f74 c3871f54 c0088eb8 bf00608c 00000004 c38e5180 c38e5160
19 1f60: c3871f78 00000000 c3871fa4 c3871f78 c0088ffc c0088e04 00000000 00000000
20 1f80: 00000000 00000004 40016000 40215730 00000004 c002c0e4 00000000 c3871fa8
21 1fa0: c002bf40 c0088fc0 00000004 40016000 00000001 40016000 00000004 00000000
22 1fc0: 00000004 40016000 40215730 00000004 00000001 00000000 4021765c 00000000
23 1fe0: 00000000 bea60964 0000266c 401adb40 60000010 00000001 00000000 00000000
24 Backtrace:
25 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)
26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)
27 r7:00000000 r6:c3871f78 r5:c38e5160 r4:c38e5180
28 [] (sys_write+0×0/0×74) from [] (ret_fast_syscall+0×0/0x2c)
29 r8:c002c0e4 r7:00000004 r6:40215730 r5:40016000 r4:00000004
30 Code: e1a0c00d e92dd800 e24cb004 e3a00000 (e5800000)
1行惊讶的原因，也就是报告出错的原因；
2-4行是OOP信息序号；
5行是出错时内核已加载模块；
6行是发生错误的CPU序号；
7-15行是发生错误的位置，以及当时CPU各个寄存器的值，这最有利于我们找出问题所在地；
16行是当前进程的名字及进程ID
17-23行是出错时，栈内的内容
24-29行是栈回溯信息，可看出直到出错时的函数递进调用关系（确保CONFIG_FRAME_POINTER被定义）
30行是出错指令及其附近指令的机器码，出错指令本身在小括号中
反汇编faulty.ko（ arm-linux-objdump -D faulty.ko faulty.dis ；cat faulty.dis）可以看到如下的语句如下：
0000007c :
7c: e1a0c00d mov ip, sp
80: e92dd800 stmdb sp!, {fp, ip, lr, pc}
84: e24cb004 sub fp, ip, #4 ; 0×4
88: e3a00000 mov r0, #0 ; 0×0
8c: e5800000 str r0, [r0]
90: e89da800 ldmia sp, {fp, sp, pc}
定位出错位置以及获取相关信息的过程：
9 pc : [] lr : [] psr: a0000013
25 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)
26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)
出错代码是faulty_write函数中的第5条指令（(0xbf00608c-0xbf00607c)/4+1=5），该函数的首地址是0xbf00607c，该函数总共6条指令（0×18），该函数是被0xc0088eb8的前一条指令调用的（即：函数返回地址是0xc0088eb8。这一点可以从出错时lr的值正好等于0xc0088eb8得到印证）。调用该函数的指令是vfs_write的第49条（0xc4/4=49）指令。-objdumpwindows
达到出错处的函数调用流程是：write(用户空间的系统调用)–sys_write–vfs_write–faulty_write
OOP消息不仅让我定位了出错的地方，更让我惊喜的是，它让我知道了一些秘密：1、gcc中fp到底有何用处？2、为什么gcc编译任何函数的时候，总是要把3条看上去傻傻的指令放在整个函数的最开始？3、内核和gdb是如何知道函数调用栈顺序，并使用函数的名字而不是地址？ 4、我如何才能知道各个函数入栈的内容？哈哈，我渐渐喜欢上了让内核惊讶，那就再看一次内核惊讶吧。-objdumpwindows
执行 cat /dev/faulty，内核又再一次惊讶！
1 Unable to handle kernel NULL pointer dereference at virtual address 0000000b
2 pgd = c3a88000
3 [0000000b] *pgd=33a79031, *pte=00000000, *ppte=00000000
4 Internal error: Oops: 13 [#2] PREEMPT
5 Modules linked in: faulty
6 CPU: 0 Not tainted (2.6.22.6 #4)
7 PC is at vfs_read+0xe0/0×140
8 LR is at 0xffffffff
9 pc : [] lr : [] psr: 20000013
10 sp : c38d9f54 ip : 0000001c fp : ffffffff
11 r10: 00000001 r9 : c38d8000 r8 : 00000000
12 r7 : 00000004 r6 : ffffffff r5 : ffffffff r4 : ffffffff
13 r3 : ffffffff r2 : 00000000 r1 : c38d9f38 r0 : 00000004
14 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
15 Control: c000717f Table: 33a88000 DAC: 00000015
16 Process cat (pid: 767, stack limit = 0xc38d8258)
17 Stack: (0xc38d9f54 to 0xc38da000)
18 9f40: 00002000 c3c105a0 c3c10580
19 9f60: c38d9f78 00000000 c38d9fa4 c38d9f78 c0088f88 c0088bb4 00000000 00000000
20 9f80: 00000000 00002000 bef07c80 00000003 00000003 c002c0e4 00000000 c38d9fa8
21 9fa0: c002bf40 c0088f4c 00002000 bef07c80 00000003 bef07c80 00002000 00000000
22 9fc0: 00002000 bef07c80 00000003 00000000 00000000 00000001 00000001 00000003
23 9fe0: 00000000 bef07c6c 0000266c 401adab0 60000010 00000003 00000000 00000000
24 Backtrace: invalid frame pointer 0xffffffff
25 Code: ebffff86 e3500000 e1a07000 da000015 (e594500c)
26 Segmentation fault
不过这次惊讶却令人大为不解。OOP竟然说出错的地方在vfs_read（要知道它可是大拿们千锤百炼的内核代码），这怎么可能？哈哈，万能的内核也不能追踪函数调用栈了，这是为什么？其实问题出在faulty_read的43行，它导致入栈的r4、r5、r6、fp全部变为了0xffffffff，ip、lr的值未变，这样一来faulty_read函数能够成功返回到它的调用者——vfs_read。但是可怜的vfs_read（忠实的APTCS规则遵守者）并不知道它的r4、r5、r6已经被万恶的faulty_read改变，这样下去vfs_read命运就可想而知了——必死无疑！虽然内核很有能力，但缺少了正确的fp的帮助，它也无法追踪函数调用栈。-objdumpwindows
36 ssize_t faulty_read(struct file *filp, char __user *buf,
37 size_t count, loff_t *pos)
38 {
39 int ret;
40 char stack_buf[4];
41
42
43 memset(stack_buf, 0xff, 20);
44 if (count 4)
45 count = 4;
46 ret = copy_to_user(buf, stack_buf, count);
47 if (!ret)
48 return count;
49 return ret;
50 }
00000000 :
0: e1a0c00d mov ip, sp
4: e92dd870 stmdb sp!, {r4, r5, r6, fp, ip, lr, pc}
8: e24cb004 sub fp, ip, #4 ; 0×4
c: e24dd004 sub sp, sp, #4 ; 0×4，这里为stack_buf[]在栈上分配1个字的空间，局部变量ret使用寄存器存储，因此就不在栈上分配空间了-objdumpwindows
10: e24b501c sub r5, fp, #28 ; 0x1c
14: e1a04001 mov r4, r1
18: e1a06002 mov r6, r2
1c: e3a010ff mov r1, #255 ; 0xff
20: e3a02014 mov r2, #20 ; 0×14
24: e1a00005 mov r0, r5
28: ebfffffe bl 28 //这里在调用memset
78: e89da878 ldmia sp, {r3, r4, r5, r6, fp, sp, pc}
这次OOP，深刻地认识到：
内核能力超强，但它不是，也不可能是万能的。所以即使你能力再强，也要和你的team member搞好关系，否则在关键时候你会倒霉的；
出错的是faulty_read，vfs_read却做了替罪羊。所以人不要被表面现象所迷惑，要深入看本质；
内核本来超级健壮，可是你写的驱动是内核的组成部分，由于它出错，结果整体崩盘。所以当你加入一个团队的时候一定要告诫自己，虽然你的角色也许并不重要，但你的疏忽大意将足以令整个非常牛X的团队崩盘。反过来说，当你是team leader的时候，在选团队成员的时候一定要慎重、慎重、再慎重，即使他只是一个小角色。-objdumpwindows
千万别惹堆栈，它一旦出问题，定位错误将会是一件非常困难的事情。所以，千万别惹你的领导，否则将死得很难看。
