panic、oops、crash都是指linux kernel层发生了内核无法处理的异常。
应用层编程只会造成该进程的崩溃，内核层的编程如驱动代码中的异常最严重的情况会导致内核panic。
那怎样处理呢？
内核panic后有dump机制会打印出目前的所有寄存器，以便于分析异常原因。
我们经常用到的工具为addr2line,objdump,gdb
addr2line可以将出错代码地址转转换成代码所在文件所在行。
objdump可以将bin文件（内核就是vmlinux了）反编译成代码文本文件
gdb可以运行代码进行调试，可以看到更多的panic附近的信息，但对于偶发的panic就不起作用了
实例：
平台：高通SDM450
系统：android 8
linux版本：linux3.18
以一个人为制造的简单panic为例简单介绍一下上述工具的使用：
1，在kernel\drivers\spi\spidev.c驱动的__init函数中添加空指针赋值，如下：
2，运行后看到panicde的log，其中有PC已经解析出了出错位置spidev_init+0x28/0x1f8
另外重点需要关注的就是pc、lr指针（pc：当前CPU运行位置，lr：函数返回地址，以定位函数被调关系）
3，android系统使用的交叉编译工具链上这三个工具分别为：
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-addr2line
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-objdump
prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi-gdb
3.1，addr2line
3.2，objdump
上述命令需要执行很久，得到的文件也十分大，可以指定起始、结束地址，只反汇编一小部分就会很快了：
应用层编程只会造成该进程的崩溃，内核层的编程如驱动代码中的异常最严重的情况会导致内核panic。
那怎样处理呢？
内核panic后有dump机制会打印出目前的所有寄存器，以便于分析异常原因。
我们经常用到的工具为addr2line,objdump,gdb
addr2line可以将出错代码地址转转换成代码所在文件所在行。
objdump可以将bin文件（内核就是vmlinux了）反编译成代码文本文件
gdb可以运行代码进行调试，可以看到更多的panic附近的信息，但对于偶发的panic就不起作用了
实例：
平台：高通SDM450
系统：android 8
linux版本：linux3.18
以一个人为制造的简单panic为例简单介绍一下上述工具的使用：
1，在kernel\drivers\spi\spidev.c驱动的__init函数中添加空指针赋值，如下：
2，运行后看到panicde的log，其中有PC已经解析出了出错位置spidev_init+0x28/0x1f8
另外重点需要关注的就是pc、lr指针（pc：当前CPU运行位置，lr：函数返回地址，以定位函数被调关系）
3，android系统使用的交叉编译工具链上这三个工具分别为：
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-addr2line
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-objdump
prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi-gdb
3.1，addr2line
3.2，objdump
arm-linux-androideabi-objdump -S vmlinux >obj.txt上述命令需要执行很久，得到的文件也十分大，可以指定起始、结束地址，只反汇编一小部分就会很快了：
arm-linux-androideabi-objdump -S --start-address=0xc153b944 --stop-address=0xc153b964 vmlinux >obj_partition.txtgdb中使用b指令也可以看到出错代码位置，若需要调试要编译带调试信息的kernel，暂未测试。
