À un moment donné, il devient nécessaire de déboguer un programme qui ne peut pas être débogué sur un ordinateur en état de marche. Dans mon cas, j'avais besoin de déboguer un programme qui communique via D-Bus avec iwd , un démon qui gère les connexions Wi-Fi, sur un ordinateur portable.
VSCode a un module complémentaire de développement à distance spécialement conçu pour de tels cas. Il ne me convenait pas pour plusieurs raisons:
- La signature automatique des commits GnuPG à partir de VSCode ne fonctionnait pas.
- L'agent SSH n'a pas fonctionné (probablement en raison de la désactivation du transfert d'agent).
- Il semblerait que l'ouverture d'un répertoire local sur une machine distante, qui semblait exister dans RD, n'a pas fonctionné (certains des fichiers nécessaires n'étaient pas inclus dans le contrôle de version, et je ne voulais pas faire de copie manuelle sur le réseau à chaque fois).
J'écris en Go, donc le hack que je vais décrire est pour le débogueur Delve . L'approche elle-même change peu quel que soit le langage de programmation; similaire peut être fait pour VSCode utilisé dans Python ptvsd et tout autre débogueur permettant des connexions à distance.
- Nous écrivons un script qui construit un binaire avec prise en charge du débogage, le copie sur la machine cible via SCP et démarre Delve.
- Créez un profil de débogage dans VSCode qui s'attache à la machine cible.
- Créez une tâche dans VSCode qui exécute le script de l'étape 1 et ajoutez-la en fonction du profil de débogage.
Scripting Delve Build and Run
Delve peut fonctionner en mode serveur de débogage, permettant aux clients de se connecter sur le réseau.
// 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"
}
}
]
}
Une fois que tout est configuré, vous pouvez appuyer sur F5, une session de débogage démarrera:
Cette méthode fonctionne, mais elle a une grande limitation: le terminal intégré à VSCode n'affiche pas les E / S standard du processus en cours de débogage. S'ils sont nécessaires, après avoir démarré le débogage, vous pouvez SSH sur la session tmux dans laquelle le programme s'exécute en arrière-plan.