但是很多ARM Linux专用设备是没有图形界面和显示器的,当出现问题时,可以在ARM设备上运行gdbserver,然后在PC机上运行vscode图形调试界面进行图形化调试就成一种重要排查手段,近年来ARM CPU往往是双核,四核,性能跟小电脑一样,这种远程调试不算太慢。这一次我排查是一个RV1126 上应用的段错误问题,就用上这个手段。
开发环境
首先要在ARM板上移植gdb和gdbserver ,然后把gdb布署到RV1126板上
具体过程可以参考我的另一篇文章
《瑞芯微 RV1126上gdb移植和调试,适用于所有armv7的CPU》
然后在PC机上安装 gdb-multiarch
sudo apt install gdb-multiarch
当然还要安装vscode
编译和调试准备
首先所有代码要用-g参数加入调试信息,为了保险可以用-O0 取消所有优化。
在vscode中要新建一个launch.json.json的执行文件来配置远程调试
点击左侧运行和调试,点击“创建launch.json文件"
通常会提供一个模板给你改写,但我只有两行,所以直接拷贝进去如下模板
{
// 使用 IntelliSense 了解相关属性。
// 悬停以查看现有属性的描述。
// 欲了解更多信息,请访问: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb)",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/bin/track",
"stopAtEntry": true,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"launchCompleteCommand": "exec-run",
"MIMode": "gdb",
"miDebuggerPath": "/usr/bin/gdb-multiarch",
"miDebuggerServerAddress": "192.168.144.99:6666",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
这里你需要调整是"program",即你要调试程序在pc机上路径
miDebuggerPath是pc上调试器,这里我选gdb-multiarch
miDebuggerServerAddress 是ARM的IP和gdbserver端口,这里是6666.
其余无需改动。
完整的调试流程
首先在RV1126运行gdbserver
gdbserver :6666 ./track
:6666 表示在6666端口监听,要与launch.json中的端口要一致。
./track是被调试的程序,一运行就等待远程的gdb接入
[root@RV1126_RV1109:/rktrack/bin]# gdbserver :6666 ./track
Process ./track created; pid = 919
Listening on port 6666
新建launch.json后,在vscode上左上角出现一个gdb的启动项,点击绿色三角即可进入远程调试,按常规会在main函数第一行停下, 在下面调试控制台会输出gdb相应输出。
如果是这样表示整个环境创建成功。
在vscode正上方有传统的调试按钮(继续,跳过,进入,跳出),在源码左侧可以点击设置断点。
继续运行可以看到在断点停下来,并且在下方的调试控制也有相应信息,甚至可以直接输入gdb 命令
可以把光标移动到变量看到当前值,也能在右键菜单下添加监视在左侧监视栏看到实时值
这个跟一般本地调试没有区别。
这个调试器看起来无法直接调试应用程序带的动态库的源码,这是gdb的问题。
希望这个文章能帮到你。