gdb远程及本地调试的一些技巧

gdb远程调试的一些技巧

大家应该都知道,调试远程程序可以用gdbserver, 

1 .生成可调试程序

比如一个源文件:main.cpp

交叉编译生成test 加-g生成调试信息.

arm-linux-gcc main.cpp -g -o test 

千万不要strip,否则调试信息就不存在了.

 

2. gdbserver调试

假设板子IP为192.168.0.19,   pc ip为192.168.0.108

板子上: 

gdbserver 192.168.0.108:2345 ./test

 pc上:

 gdbx86 ./test

gdbx86得自行编译gdb源码生成针对arm平台的程序, This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux". 网上可查

连接gdbserver(怎么编译生成它网上有文章)

target remote 192.168.0.19:2345

然后就可以 下断点了, 然后 c 程序开始跑.

 

1,2两点估计做嵌入式开发的都知道, 3则可能有些人没有遇到过

3  调试远程开发板产生的core 

板子上使能core dump

ulimit -c unlimited

然后跑程序 

./test

如果程序产生core , 不用gdbserver, 直接把core挎到pc上, 然后用上面提到的gdbx86调试它,

gdbx86 ./test  core  

 

 

 

其实在潜入式开发中，coredump应该还是挺多的，而且能快速定位到死机问题。

在开发阶段，容易发生各种死机，结合实际开发中的问题说明下gdb调试coreump

就Mstar方案，死机时会后Coredump文件生成，其属于process的“尸体”，而linux提供了不错的“尸检”工具gdb，运用gdb来调试Coredump一般能够较快定位到普通的死机问题，其主要步骤如下：

a）准备好gdb（目前我们使用的为mips-gdb，其运行与6328平台，可以从\\10.120.99.100\f1\luoyangzhi找到，通过tftp下载到目标平台，即6328开发板，可以放在/applications/bin下）

b）Mstar死机文件一般为/applications/Coredump.gz，其是压缩后的Coredump文件

c）一般来说这个Coredump.gz文件解压后较大，所以我们需要将其解压到U盘里，所以调试的时候需要插入U盘并成功挂载

d）解压Coredump.gz文件（假设U盘挂载目录为/usb/sda1/,则可以使用如下命令：zcat /applications/Coredump.gz > /usb/sda1/ Coredump）,这里的速度更U盘速度相关

e）开始调试死机的程序，（此处假设为tvh_service_socketS死机），使用如下命令：

f）在gdb提示符下指定coredump文件，其会加载所有的动态库等

g）在gdb提示符下输入bt，一般情况下进程的函数调用堆栈会清晰的告诉你哪里死机了（此处暂时没有配图，见谅）

看上去好像很复杂，其实以后就这三板斧：

1. 解压得到coredump文件（zcat /applications/Coredump.gz > /usb/sda1/ Coredump）

2. 开调， gdb打开执行文件，并引入coredump文件

gdb 可执行文件 coredump文件 或者 gdb 可执行文件；core-file

 

 

 & 

3.  bt一次

 

App_bin引起的死机。

1、zcat Coredump.gz > Coredump 

进入到mips-gdb所在目录（例如/applications/bin）

2、./mips-gdb app_bin /applications/Coredump 

（app_bin引起coredump的bin，/applications/Coredump （coredump所在目录）

3、(gdb) bt