mstar gdb调试

当进程崩溃出现coredump提示时,可以利用gdb来定位出错函数。

首先,把core_dump.XXX.gz文件从设备上拷贝出来,放到编译环境下,另外,还要把代码目录下的symbols文件夹也拷贝到编译环境下,因为程序用到很多库,很多时候出错是在库函数里,所以一定要拷贝当前编译时产生的symbols文件夹,android一般在out/target/product/下,Supernova一般在projects/目录下。

先解压core_dump.XXX.gz文件,然后用gbd命令调试它,如下命令:

/opt/toolchain/mstar/arm-2012.09/bin/arm-none-linux-gnueabi-gdb -core core_dump.1029/Coredump.gz

/opt/toolchain/mstar/arm-2012.09/bin/arm-none-linux-gnueabi-gdb就是刚才找到的命令工具,-c或-core是指调试core文件,后面是文件路径。回车后,弹出的命令行(gdb)就是调试命令行了。

(gdb) backtrace命令是查看当前线程函数栈回溯,简写是bt。

如果bt后都是问号,看不到函数名,说明运行到动态库里出错了。

用file命令载入调试的文件,假如提示是由/applications/bin/tvos产生的core,就载入这个二进制文件,这个文件也就在symbols/applications/bin/下。

还要载入库文件,可以用set sysroot、set solib-absolute-prefix、set solib-search-path来指定库搜索路径,set sysroot是set solib-absolute-prefix 的别名,set solib-absolute-prefix设置库的绝对路径前缀,而solib-search-path设置库的搜索路径,对绝对路径和相对路径均起作用。

设置好后,再backtrace,就可以看到具体出错的函数在哪儿了,可以定位到具体行数,这时去查代码就行了。

若是遇到multithread mutex/semaphore deadlock问题,可以输入”thread apply all bt”, 一次查看所有threads的backtrace.

你可能感兴趣的:(mstar gdb调试)