Esegui il debug del codice C ++ in Vim? Come?

La domanda è rivolta a tutti voi, che utilizzate Vim per sviluppare applicazioni C ++.

C'è stato un periodo della mia vita, che può essere descritto come "Odio Vim !!!". "Vim è bello!"

Tuttavia, essendo cresciuto principalmente su IDE di sviluppo Microsoft, mi sono abituato a questi F5- F11scorciatoie durante il debug del codice, watch window, stack di chiamate e il codice principale - tutti visibili senza la necessità di digitare alcun comando GDB.

Quindi, ecco la domanda:

Usi Vim anche per il debug? O passi a qualche IDE per questo scopo? Quale?

Per coloro che usano Vim per il debug del codice: ci sono plugin per impostare i punti di interruzione nell'editor, evidenziare la linea che stiamo attualmente eseguendo il debug, la navigazione automatica durante il passaggio, entrare, uscire?

Per favore, non dirmi che usi GDB come riga di comando, vedi solo una riga che è stata sottoposta a debug, ecc.

Contrariamente alle altre risposte, ci sono almeno tre opzioni che fanno proprio quello che ti serve: clewn , pyclewn e vimgdb .

Tutti e tre i progetti sono correlati. vimgdb è una patch contro Vim e richiede che Vim sia ricompilato. clewn è un programma autonomo che comunica con Vim attraverso l'interfaccia socket di Netbeans. Ciò richiede che Vim sia compilato con l' +netbeansopzione (questo è il caso delle recenti distribuzioni Linux, quindi non dovrebbe essere un problema).

Per citare dal sito web di Clewn:

Clewn implementa il supporto completo per gdb nell'editor vim: punti di interruzione, variabili di controllo, completamento del comando gdb, finestre di assemblaggio, ecc.

Penso che dovresti assolutamente provarlo.

La homepage del sito Web di Pyclewn mostra un confronto tra i tre progetti.

Qualche mese fa ho provato Pyclewn. È stato un po 'difficile da configurare, ma sembra ben fatto e promettente. Ho appena fatto alcuni test e potresti impostare segnalibri, ecc., Le solite cose che ti aspetteresti da un debugger grafico. Ho finito per non usarlo per motivi contingenti, ma sono desideroso di provarlo ancora.

Vim ha aggiunto un debugger integrato ufficialmente nella versione 8.1, rilasciata a maggio 2018. La funzionalità era stata presente anche in alcune versioni 8.0, già nell'agosto 2017.

I seguenti comandi vim caricano il plug-in e avviano il debugger.

:packadd termdebug
:Termdebug

Quest'ultimo comando accetta un programma come argomento facoltativo, oppure in alternativa un programma può essere caricato dalla gdbfinestra con il filecomando.

Con il plugin caricato, gdbpuò essere utilizzato in modo interattivo nella finestra corrispondente. Ad esempio, è possibile impostare punti di interruzione, scorrere il codice e ispezionare le variabili.

I comandi Vim possono essere emessi per interagire con gdb. Alcuni comandi rilevanti comprendono :Step, :Over, :Finish, :Continue, :Stop, :Break, :Clear, e :Evaluate.

Inoltre, ci sono pulsanti cliccabili nella parte superiore della finestra dell'editor per interagire con gdb.

La finestra dell'editor viene aggiornata per riflettere lo stato del debug. I punti di interruzione sono indicati con >>e la riga corrente è evidenziata.

La pagina di aiuto integrata include una documentazione completa.

:help terminal-debug

Di recente ho scritto un post sul blog che illustra una sessione di esempio.

https://www.dannyadam.com/blog/2019/05/debugging-in-vim/

Vim è un buon editor, ma per fare il debug uso un debugger (come GDB).

Ma non è necessario utilizzare GDB in modalità testo; puoi usare un frontend grafico come KDbg , DDD o Insight .

Ci sono modi per ottenere GDB in Vim (ma poi ottieni il debug basato sul testo).

editComando GDB

Apre un editor sulla riga corrente usando il comando:

$EDITOR +<current-line> <current-file>

L'impostazione predefinita editorè ex, ma vimcomprende anche il +<current-line>formato.

Quando esci dall'editor, torni indietro gdb.

Ciò consente di navigare liberamente nella fonte ed è particolarmente potente se si dispone di ctagsintegrazione.

Questo è un gdb unidirezionale incorporato per i poveri per vim l'integrazione: la cosa principale mancante è impostare i punti di interruzione da Vim.

edit e al centro

editnon centra Vim per impostazione predefinita attorno alla fonte, quindi ho creato uno script Python che lo fa: Come aprire il file corrente sulla riga corrente in un editor di testo da GDB?

Comando di breakpoint nell'helper degli appunti

Questo comando vim copia un identificatore di breakpoint di tipo:

b <file-path>:<line-number>

negli appunti:

command! Xg :let @+ = 'b ' . expand('%:p') . ':' . line('.')

Quindi puoi semplicemente incollarlo in gdb.

Questa è la vim di un uomo povero per l'integrazione gdb per facilitare l'impostazione dei punti di interruzione.

Dashboard GDB

https://github.com/cyrus-and/gdb-dashboard

Questo non ha nulla a che fare con Vim, ma è una soluzione leggera che ottiene molto e potrebbe adattarsi ad altri Vimmer là fuori.

Altri hanno menzionato GDI TUI, ma l'ho trovato troppo rotto e non abbastanza potente da essere sopportabile.

Quindi sono passato invece a soluzioni basate su API Python come GDB Dashboard.

Ho descritto l'usato e la logica in modo più dettagliato in: vista divisa gdb con codice

Ecco uno screenshot di ciò che ti offre:

Vedi anche: /vi/2046/how-can-i-integrate-gdb-with-vim

Rinuncia e usa un vero IDE

Detto questo, questa è la soluzione migliore per la maggior parte delle persone, incluso me stesso. La maggior parte delle persone guadagnerà un sacco di tempo se sarà in grado di saltare le definizioni in modo consapevole in classe C ++ senza selezionare e installare diversi plug-in stessi, e questo include durante il debug di roba. A partire dal 2020 il meno peggio per me è stato Eclipse: https://www.slant.co/topics/1411/~best-ides-for-c-on-linux

L'utilizzo di un debugger a livello di sorgente è solo uno dei molti modi per diagnosticare il comportamento errato del programma e raramente mi ritrovo a lanciarne uno, nonostante sia molto facile da eseguire.

Quindi per me non c'è semplicemente alcun vantaggio intrinseco nell'uso di un editor di testo che sembra essere anche un debugger . Invece, uso l'editor di testo che preferisco, indipendentemente dal debugger che scelgo di usare. Al momento, uso principalmente gedit e kdbg per questi scopi, ma queste scelte si evolvono indipendentemente nel tempo.

Aggiornamento 2020: esiste un nuovo vimspector di plugin che utilizza il Debug Adapter Protocol

1. Installa il plugin https://github.com/puremourning/vimspector#installation

2. Configura (scrivi .vimspector.json)

3. Compilare con il simbolo di debug g++ cpp.cpp -ggdb -o cpp

4. Premere F4per avviare il debug

• Nota my .vimspector.jsonnella mia home directory (quindi lavora in qualsiasi sottodir)

{
"configurations": {
  "Python - Launch": {
    "adapter": "vscode-python",
    "configuration": {
      "name": "Python: Launch current file",
      "type": "python",
      "request": "launch",
      "stopOnEntry": true,
      "stopAtEntry": true,
      "console": "externalTerminal",
      "debugOptions": [],
      "cwd": "${cwd}",
      "program": "${file}"
    }
  },
  "Perl - Launch": {
    "adapter": "vscode-perl-debug",
    "configuration": {
      "name": "Perl: Launch current file",
      "type": "perl",
      "request": "launch",
      "exec": "/usr/bin/env perl",
      "execArgs": [],
      "stopOnEntry": true,
      "stopAtEntry": true,
      "console": "externalTerminal",
      "sessions": "single",
      "debugOptions": [],
      "cwd": "${cwd}",
      "program": "${file}"
    }
  },
  "C - Launch": {
    "adapter": "vscode-cpptools",
    "configuration": {
      "name": "Cpp: Launch current file",
      "type": "cppdbg",
      "request": "launch",
      "externalConsole": true,
      "logging": {
        "engineLogging": true
      },
      "stopOnEntry": true,
      "stopAtEntry": true,
      "debugOptions": [],
      "MIMode": "gdb",
      "cwd": "${cwd}",
      "program": "${fileDirname}/${fileBasenameNoExtension}"
    }
  },
  "Java - Launch": {
    "adapter": "vscode-java",
    "configuration": {
      "name": "Java: Launch current file",
      "request": "launch",
      "mainClass": "com.vimspector.test.TestApplication",
      "sourcePaths": [ "${workspaceRoot}/src/main/java" ],
      "classPaths": [ "${workspaceRoot}/target/classes" ],
      "args": "hello world!",
      "stopOnEntry": true,
      "console": "integratedTerminal"
    }
  }
} }

Avendo da poco lavorato su un'applicazione per molto tempo che richiedeva un sacco di cose da sistemare sulla scatola che stava funzionando (configurazione dell'appliance), ho scritto il codice in vim, avevo script che automatizzavano la costruzione, spingendolo su un server , che aveva uno script lì per notare il file sentinella inviato insieme ai binari. Questo riavvierebbe quindi i servizi appropriati sulla scatola e in un'altra finestra SSH ho avuto un tail -fesecuzione sul mio file di registro.

Per farla breve, non ho usato affatto un debugger. Se avessi fatto morire qualcosa inaspettatamente, avrei semplicemente aumentato i livelli di registrazione, ripetuto e visto quale era l'ultima cosa registrata prima che morisse, quindi analizzerei e risolvo il problema.

La cosa bella era che quando qualcosa aveva problemi nell'ambiente di un cliente, chiedevo semplicemente un registro a livello di debug e potevo identificare il problema senza nemmeno richiedere l'accesso al loro server.

... ma sì, ci sono stati momenti in cui sarebbe stato bello avere un debugger.

Solo per aggiungere a sopra:

IMO vim tende ad essere un editor abbastanza leggero e il debug tende ad aumentare di peso. Ci sono modi per farlo, ad esempio usando vim7.4 + con

:terminal

ed eseguendo uno dei seguenti debugger da riga di comando (curses). Alcuni sono usati per impostazione predefinita per gli IDE che non hai mai conosciuto. cioè lldb = xcode.

• (c / c ++ / goal c) gdb (debugger gnu) - https://www.gnu.org/software/gdb/
• (c / c ++ / goal c / python ecc.) remake - http://bashdb.sourceforge.net/remake/
• (java) debugger oracle java - https://docs.oracle.com/javase/7/docs/technotes/tools/windows/jdb.html
• (c / c ++ / obiettivo c) lldb - https://lldb.llvm.org/

ovviamente ce ne sono altri basati su cli; @tutti sentiti libero di suggerire e aggiungere alla lista. Grazie!