ある時点で、動作中のコンピューターではデバッグできないプログラムをデバッグする必要が出始めます。私の場合、ラップトップ上で、D-Busを介してWi-Fi接続を管理するデーモンであるiwdと通信するプログラムをデバッグする必要がありました。
VSCodeには、そのような場合のために特別に設計されたリモート開発アドオンがあります。彼はいくつかの理由で私に合いませんでした:
- VSCodeからのGnuPGコミットの自動署名が機能しませんでした。
- SSHエージェントが機能しませんでした(おそらくエージェント転送が無効になっているため)。
- RDに存在しているように見えるリモートマシンでローカルディレクトリを開くことができなかったようです(必要なファイルの一部がバージョンコントロールに含まれていなかったため、毎回ネットワーク経由で手動でコピーしたくありませんでした)。
私はGoで書いているので、これから説明するハックはDelveデバッガー用です。アプローチ自体は、プログラミング言語に関係なくほとんど変わりません。Python ptvsdおよびリモート接続を許可するその他のデバッガーで使用されるVSCodeについても、同様のことができます。
- , , SCP Delve.
- VSCode , .
- VSCode , .1 .
スクリプティングDelveビルドと実行
Delveはデバッグサーバーモードで動作できるため、クライアントはネットワーク経由で接続できます。
// dlv bash- Makefile, Taskfile, Taskfile.yml, shell-:
version: '2'
tasks:
killall:
cmds:
# Delve ,
# ,
#
- ssh target_machine killall dlv || true
push:
deps:
- killall
cmds:
#
- go build -gcflags="all=-N -l" -o ./build/debug_binary ./cmd/program
#
- scp ./build/debug_binary target_machine:/home/tdemin/Desktop/debug_binary
delve:
deps:
- push
cmds:
# dlv 64001;
# tmux ,
# dlv, & nohup
#
- ssh target_machine '(cd ~ && chmod +x Desktop/debug_binary && tmux new -d dlv --headless -l \[::\]:64001 exec ./Desktop/debug_binary)'
task delve; Taskfile.yml Delve ( SCP, scp dlv ), / Delve .
.vscode/launch.json, , :
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to target",
// dlv API v1 ,
// --api-version
"apiVersion": 1,
"type": "go",
"request": "attach",
"mode": "remote",
// ; ,
// , ,
//
"remotePath": "${workspaceFolder}",
// ,
//
"preLaunchTask": "Run Delve on target",
"port": 64001,
"host": "target_machine"
}
]
}
.vscode/tasks.json :
{
"version": "2.0.0",
"tasks": [
{
// preLaunchTask launch.json
"label": "Run Delve on target",
"type": "shell",
// Taskfile
"command": "task delve",
"group": {
"kind": "test",
"isDefault": true
},
"presentation": {
//
// ,
"reveal": "silent"
}
}
]
}
すべてが構成されたら、F5キーを押すと、デバッグセッションが開始されます。

この方法は機能しますが、大きな制限が1つあります。VSCodeに組み込まれている端末は、デバッグ中のプロセスの標準I / Oを表示しません。それらが必要な場合は、デバッグを開始した後、プログラムがバックグラウンドで実行されているtmuxセッションにSSHで接続できます。