本文主要是介绍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调试的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
