VScode 远程调试进阶
背景
这里是 VScode 远程调试的进阶用法，或者说是 gdb 的进阶用法，因为这其实跟 VScode 的关系不大，虽然修改的 launch.json 即 VScode 的调试配置文件，但是其实本质上是调用 gdb 的命令行而已。
原始配置
这里给出没有做出以下改进前 launch.json 的配置：
{
"version": "0.2.0",
"configurations": [
{
"name": "web_tc(launch)",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/bin/web_tc",
"args": [
"${workspaceRoot}/bin/config.json"
],
"stopAtEntry": true,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "为 gdb 启用整齐打印",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "complie",
"miDebuggerPath": "/home/haorui/tools/arm-hisiv600-linux-gdb/bin/arm-hisiv600-linux-gdb",
"miDebuggerServerAddress": "172.20.92.88:10020"
}
]
}
本地加载动态库
默认情况下，如果启动远程调试时，你会解决启动地比较慢，可能需要几秒钟的时间，这里的时间开销很大程度上是来自于远程加载动态库所耗费的时间。
你可以在调试控制台看到类似于这样的内容:
Loaded 'target:/lib/a9_vfpv3_neon/libpthread.so.0'. Symbols loaded.
Loaded 'target:/lib/a9_vfpv3_neon/libstdc++.so.6'. Symbols loaded.
Loaded 'target:/lib/a9_vfpv3_neon/libm.so.6'. Symbols loaded.
Loaded 'target:/lib/a9_vfpv3_neon/libgcc_s.so.1'. Symbols loaded.
Loaded 'target:/lib/a9_vfpv3_neon/libc.so.6'. Symbols loaded.
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
这基本上就是导致你远程调试启动很慢的主要原因，你需要做的就是把目标机的这些文件拷贝到宿主机(也就是你的虚拟机)的某一个地方。
怎么拷贝过来那又是另外一回事了，你可以使用 nfs 、ftp 或者 ssh 等等，总而言之把目标机上的 lib 拷贝回来。
上图多打了一个
path
然后重定义加载的目录,动态库加载不使用远程自动加载，而采取本地指定搜索路径，本地加载，效果如下：
Loaded '/home/haorui/tools/lib/a9_vfpv3_neon/libpthread.so.0'. Symbols loaded.
Loaded '/home/haorui/tools/lib/a9_vfpv3_neon/libstdc++.so.6'. Symbols loaded.
Loaded '/home/haorui/tools/lib/a9_vfpv3_neon/libm.so.6'. Symbols loaded.
Loaded '/home/haorui/tools/lib/a9_vfpv3_neon/libgcc_s.so.1'. Symbols loaded.
Loaded '/home/haorui/tools/lib/a9_vfpv3_neon/libc.so.6'. Symbols loaded.
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
这样能够大幅度提高你对 gdb 用户体验感。
多进程调试
默认情况下 gdb 是不能调试多进程的，但是 gdb 可以通过一些命令行开启这项功能，如下：
然后你就可以捕获多个进程了，以下给出一张效果图：
当然你得在
fork之前就把断点打好。
如果你不是用这些额外配置的话，那么效果就会像以下这样了:
即子进程是不能捕获到的，在配置中也出现了 detach ，你可以了解以下它的用法。
当然即使如此还是非常的不方便，目前没有找到解决方案，因为它们看起来就像是两个不同的线程，而非不同的进程；这个一直都没有解决，无论是 VScode 还是 Qt，都是这么感人，捕获的子进程也放在了 调用堆栈 , 这样是很难区分这个线程究竟是属于哪一个进程的；一种比较推荐的方案就是给线程起名字。
detach 进程
这个说起来是真的比较尴尬， VScode 好像 GDB 的插件做的有点阉割，原生态是不支持 detach 进程的，所以说是 detach,但是 launch.json 是没有变化的，实际上还是要自己去 detach 进程的。
