站长资源服务器

解决VScode配置远程调试Linux程序的问题

整理:jimmy2024/12/23浏览2
简介下面看下VScode远程调试Linux程序的问题,具体内容如下,一起看看吧!最近在Linux上调程序,但是gdb使用属于入门阶段,主要是没有图形化界面直观。在网上查找了有两个方案可选,一个是通过VisualStudio2019的远程调试功能,因为最近一直在用VScode,所以没有试,之后有时间了可

下面看下VScode远程调试Linux程序的问题,具体内容如下,一起看看吧!

最近在Linux上调程序,但是gdb使用属于入门阶段,主要是没有图形化界面直观。在网上查找了有两个方案可选,一个是通过VisualStudio2019的远程调试功能,因为最近一直在用VScode,所以没有试,之后有时间了可以试一下。另一个方案就是通过VScode的Remote Development插件(微软官方提供的)进行远程调试。本文介绍下这个方案。
虽然网上也有其他的文章进行介绍,但是都是写的成功的情况,没有写出来过程遇到的问题,而且有些地方不太清楚。所以我觉得自己写一个。另外请大家注意的是,这篇文档介绍的是远程调试,并不介绍远程编译,远程调试VScode也是支持的,但是我目前不需要,后续如果需要再做配置,而且我的项目需要使用cmake及make进行编译,并不是直接用g++编译,所以也没有开始配置。
VScode的远程调试是利用gdbserver的机制进行的。大体原理是通过在Windows上或者其他图形化系统上的VScode,使用Remote Development插件进行ssh连接到远程Linux上,然后通过gdbserver提供的连接进行远程调试。下面开始介绍具体配置方式。

需要的软件及插件

首先肯定需要安装gdb和gdbserver,大家根据自己远程系统的类别进行安装就行了。我用的Ubuntu,默认已经安装了。命令如下:

sudo apt install gdb
sudo apt install gdbserver

其次需要安装VScode的Remote Development插件,官方的C/C++插件。对于这个C/C++插件等远程连接到Linux上之后,还需要安装到远程Linux上。可以看我下面的截图,在插件的卸载按钮旁边有个“已在SSH:x.x.x.x上启用扩展”,这是已经安装过的。后面到连接成功后介绍安装方法。

解决VScode配置远程调试Linux程序的问题解决VScode配置远程调试Linux程序的问题

远程连接

在安装了Remote Development插件后,就可以远程连接Linux了,ssh的连接方式有两种,一种是账户密码。还有一种是公私钥连接。这里推荐使用公私钥连接,因为后面远程调试过程会多个地方连接,需要多次输入密码比较麻烦,使用公私钥的话只需要配置一次就可以了,非常方便。仍然选择账户密码连接的可以跳过此处。ssh远程配置方法比较简单,但是在Windows上有个大问题。

首先在远程Linux上生成公私钥对:

# 执行下面命令,然后根据提示生成公私钥对。
ssh-keygen -t rsa

# 公钥直接在生成路径中保存,然后转存为authorized_keys
# 存储到用户的.ssh目录中,一般在生成的时候,默认路径就是用户的.ssh目录
# 假设生成的公钥是 "vscode_rsa.pub",最后注意权限设置,默认不需要改。
cat /home/user/.ssh/vscode_rsa.pub  /home/user/.ssh/authorized_keys
chmod 644 /root/.ssh/authorized_keys

# 私钥下载到Windows机器里
# 假设路径是 "D:/.ssh/vscode_rsa"

到这里都是没有问题的。现在需要在VScode中配置连接了。
安装完Remote Development插件后,在VScode最左边有个远程资源管理器图标,如下图所示,然后选择SSH Targets,点击加号,按照user@ip的格式添加,然后根据提示会看到远程连接的配置文件。或者直接在下面界面上加号旁边的齿轮,直接打开配置文件,按照下面的格式添加,在IdentityFile后面添加私钥的路径:

解决VScode配置远程调试Linux程序的问题

Host x.x.x.x
 HostName x.x.x.x
 User username
 IdentityFile D:/.ssh/vscode_rsa

然后就可以在原先的文件浏览界面,打开远程的文件夹。但是在配置好进行连接的时候,VScode的终端报错了:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'vscode_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "vscode_rsa": bad permissions

根本原因是私钥的权限问题。这要是在Linux里,直接使用chmod,就可以修改,修改为644即可,但是windows,就稍微麻烦点。

解决办法:

在私钥上右击选择属性,然后选择【安全】选项卡,然后点击下面的【高级】按钮,然后在新弹出的窗口下方点击【禁用继承】,然后点击继承那个按钮上面的【添加】按钮重新将当前window登录用户设置为私钥的所有者,并勾选所有权限。最后跟下面一样即可:

解决VScode配置远程调试Linux程序的问题

这时再次打开VScode远程连接,就没有问题了。

远程调试

VScode设置

首先需要将刚才说的C/C++插件安装到远程Linux上,安装方法简单,点击插件,在已安装插件里面可以看到有的插件会有一个【在SSH:IP】的绿色提示,找到C/C++插件,点击那个绿色提示,将其安装到远程Linux上。安装完之后,重新启动VScode,最好也重新启动远程Linux,因为我就是没有启动,在后面操作的时候,VScode提示找不到所选的调试器类型,也不会自动根据你选的调试器生成launch.json文件。但是如果你不重启也能成功的话,最好。
然后打开VScode的资源管理器,就是左侧最上面那个浏览文件的,会提示打开远程文件夹,这时只需要按提示打开需要调试的程序所在的文件夹即可。

然后在菜单栏里选择运行->添加配置,会弹出提示选择调试环境,这是选择【C++ GDB/LLDB】那个即可自动生成launch.json文件。如下:

{
 // 使用 IntelliSense 了解相关属性。 
 // 悬停以查看现有属性的描述。
 // 欲了解更多信息,请访问: https://go.microsoft.com/fwlink/"version": "0.2.0",
 "configurations": [
 {
  "name": "(gdb) 启动",
  "type": "cppdbg",
  "request": "launch",
  "program": "${workspaceFolder}/program",
  "args": [],
  "stopAtEntry": true,
  "cwd": "${workspaceFolder}",
  "environment": [],
  "externalConsole": false,
  "MIMode": "gdb",
  "setupCommands": [
  {
   "description": "为 gdb 启用整齐打印",
   "text": "-enable-pretty-printing",
   "ignoreFailures": true
  }
  ]
 }
 ]
}

如果没有自动生成,则说明VScode没有识别环境,你安装的插件还没有生效,所以需要重启VScode以及远程Linux。
生成的launch.json文件需要修改的地方就是program字段,${workspaceFolder}是指你刚才打开的远程文件夹,只需要在后面指定待调试程序的名称即可。stopAtEntry字段,默认是false,这是指开始调试的时候是否在main函数断点,所以改为true。其他使用默认的就行,也不需要添加什么。

远程Linux开启gdbserver

在远程Linux上开启gdbserver,开启方式如下:

#gdbserver localhost:<port> <program> <args>
gdbserver localhost:2333 /path/to/myprogram arg1 arg2

注意端口号不要改,VScode连接的时候默认就是用的这个端口号。然后在VScode中直接按F5就可以调试了,gdb会自动查看源代码的,所以你这个待调试的程序最好是debug版的。

参考文章:

https://warmgrid.github.io/2019/05/21/remote-debug-in-vscode-insiders.html

https://superuser.com/questions/1296024/windows-ssh-permissions-for-private-key-are-too-open