一种基于VSCode的嵌入式开发的可视化代码调试方法

关键字： VSCode、gdbserver、可视化调试、嵌入式开发

• 案例简述

随着本组业务的扩大，新进组员的增多，在开发定制或者排查基线的问题时候，经常会遇到问题不是那么明显，不方便通过加打印的方式进行排查的问题，并且加打印排查的方式较为低效，使得调试过程极为痛苦。

可视化调试效率一直比命令行调试要方便和快捷很多，而嵌入式开发由于目标程序在开发板上，而不在编写代码本身的环境中，这样的程序运行环境和编译环境分离的情况，导致普通的集成开发环境并不能满足嵌入式开发可视化调试的需求。虽然嵌入式开发有gdbserver这种可以远程调试的工具，但由于部署环境较为复杂并且指令式的调试方法不友善等原因，一直鲜有人使用。

目前找到了一种基于VSCode的可视化嵌入式代码调试方式，可以近似于使用VS一样的进行代码调试，极大的增大了调试程序的便利性，使调试代码更加容易。

• 案例分析和解决过程

环境部署：

1. 交叉工具链需要支持gdb，gdbserver；
2. 调试电脑上需要有VScode；
3. 调试电脑上需要有arm-2014.05-29-arm-none-linux-gnueabi.exe，并且安装成功；

 

实际调试案例步骤：

1. 用VSCode打开代码工程目录；
2. 在VSCode自动生成的.vscode文件夹中新增launch.json文件，具体lanuch.json文件的配置方式如图2-1所示，其中：

miDebuggerServerAddress：这个地方填写的是板子的ip地址和在板子上需要启动的gdbserver启动参数中的端口号。

program：填写的必须是板子上运行的目标程序和工作文件夹之间的路径关系，最后虽然实际程序并不会运行，但是路径里最后的可执行文件必须和放到板子里的一致。

cwd：这个参数和program类似，但是不需要指定到具体的可执行文件上，而是可执行文件的所属目录。

miDebuggerPath：这个参数主要是填写环境部署中，arm-2014.05-29-arm-none-linux-gnueabi.exe这个程序安装好后，arm-none-linux-gnueabi-gdb.exe这个可执行程序的路径位置。

 

图2-1  launch.json文件配置样例

         设置好后，将arm-at91-linux-gnueabi-gdbserver和目标程序一并加载至开发板中，在任意路径启动arm-at91-linux-gnueabi-gdbserver {主机ip:主机端口号} {目标程序路径}，对于本例而言，即启动 arm-at91-linux-gnueabi-gdbserver 10.10.114.28:9001 ./hikTSC400。此事，板子上所有的操作完成，板子上会提示如图2-2的信息，并等待调试客户端连入。

 

         图2-2  板子上启动gdbserver后提示

         此时，在设置好launch.json的VSCode客户端上，按F5进入调试模式即可连上板子并进行响应调试，可以发现板子上的程序开始执行。并且VSCode客户端中已经有相应的可视化调用栈，变量区域打印。

 

图2-3  VSCode客户端开始调试时候的样例

值得说明的是，在可视化的模式下，也依旧支持命令行的方式进行控制，在DEBUG CONSOLE中依旧可以输入bt等常见gdb中指令，对代码进行调试。

• 经验总结、预防措施及建议

1. 需要这样调试，必须是使用的交叉工具链带有gdb的功能，并且用–g选项对可执行程序进行编译。
2. 对于一个已经进入死循环的程序，只要是-g模式编译的，一样可以在程序运行的过程中中途介入进行调试，方法为另启动一个shell，然后查看死循环程序的pid值，并运行arm-at91-linux-gnueabi-gdbserver {主机ip:主机端口号} –attach {PID号}的方式进行介入。

• 从本文可导出的检查项（checklist）

暂无

• 参考文献、标准、案例

1. https://blog.csdn.net/zhaoxd200808501/article/details/77838933
2. https://blog.csdn.net/wynter_/article/details/102481531