当kernel发生异常时，会在重启后生成对应的db，用GAT的logviewer可以解开，如果是普通的KE或HWT，并且存在SYS_MINI_RDUMP或者SYS_COREDUMP，则可以借助gdb/crash进一步debug，否则只能查看log分析问题的可能性了。
#1、GAT （定位死机重启等问题发生的可能原因）
- 在MTK官网上Tool下可以下载到对应的工具；
- 在Linux环境下使用记得解压的目录对应的是linux版本的；
- 当发生SWT、NE或KE的时候会在mtklog/aee_exp(或data/aee_exp)目录可以找到对应的*SWT.dbg、db.fatal.00.NE.dbg等文件，通过GAT解开db.fatal.00.SWT.dbg、db.fatal.00.NE.dbg。（aee_exp/xxx.dbg,如果sdcard没有就尝试去data/aee_exp取，注意Android8.0后需要去/data/vendor/mtklog目录取.）
- 首先定位问题发生的原因、类型。
解开上述文件之后，会有backtrace,这就是分析问题的入口点。
#2、使用gdb/addr2line/c++flit工具(分析栈，转为源码分析)
结合上下文，分析关键线程的调用栈，用工具解析出调用栈，`转为源码级分析`
#3、NE问题
对于复杂NE问题可能需要打开coredump支持，重新复现问题抓取coredump使用工具离线分析, N版本开启coredump方式：
setprop persist.aee.core.dump enable
setprop persist.aee.core.direct enable
#4、NotePad++
强大的搜索功能，用于过滤log.
#5、addr2line/gdb/objdump/c++filt
用于解析backtrace，工具路径：prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin
addr2line
objdump
c++filt
gdb ：对应的目录再usr/bin/gdb .....貌似之前有安装过。。。
直接启动gdb，进入gdb命令行，然后将vmlinux和SYS_MINI_RDUMP放到gdb所在的目录中，直接输入如下命令：
file vmlinux
core SYS_MINI_RDUMP
bt
最后的bt是查看当前的调用栈！
#6、Trace32
主要用到它的模拟器功能，调试方法跟gdb功能类似，不同的是T32支持图行界面，用于离线调试full-ramdump比较方便（gdb只能调试mini_rdump)
#7、Crash
命令行界面，内置gdb引擎，用法跟gdb类似，主要用于离线调试full-raumdump，比如展讯平台KE标准分析工具就是这个.