Ho creato il mio frontend gdb chiamato gdbgui che è un server (in python) che ti consente di accedere a un frontend completo nel tuo browser .

  pip install gdbgui --upgrade  

o scarica da gdbgui.com

Funziona su tutte le piattaforme (Linux, macOS e Windows) e browser con JavaScript.

Esegui

Basta digitare

  gdbgui  

nel tuo terminale e il tuo browser aprirà una nuova scheda .

Caratteristiche

• imposta / rimuovi punti di interruzione
• visualizza codice sorgente, con codice macchina inline opzionale
• seleziona il frame corrente nello stack
• esplora il codice sorgente o il codice macchina
• crea / esplora variabili
• visualizza / seleziona thread
• esplora la memoria
• visualizza i registri
• funzionalità completa del terminale gdb in modo da poter inviare comandi gdb tradizionali e visualizzare l'output del programma gdb / inferiore
• layout ispirato all'ama debugger di Chrome con zing
• compatibile con RR di Mozilla, per il debug inverso

Anche se ad alcune persone non interessa la sua interfaccia, vale la pena ricordare che GDB ha anche la sua GUI incorporata (chiamata TUI).

Puoi avviare GDB in modalità GUI con il comando : gdb -tui

Un rapido riferimento ai comandi TUI può essere trovato qui: http://beej.us/guide/bggdb/#qref

In genere ho usato Emacs GUD come frontend GDB.

Non è troppo difficile da usare, ti permette per impostare visivamente i punti di interruzione (o tramite la finestra GDB se preferisci).

Ha più viste diverse a cui puoi accedere da un menu GDB di primo livello:

Permette anche sottigliezze come consentire di ispezionare i valori passandoci sopra il mouse:

Per usarlo, devi prima navigare nella cartella del tuo binario con Cx Cf , quindi Mx gdb (ovvero " Alt + X ", quindi digitando" gdb "). Dopo averlo fatto, puoi digitare una riga di comando gdb o semplicemente premere [Invio] per accettare il valore predefinito. Da lì, digita semplicemente "start" nella finestra di gdb con tutti i parametri che vuoi passare al programma di cui stai eseguendo il debug.

Dopodiché, sei praticamente d'oro, ma con una sola vista. I menu nella parte superiore dello schermo sotto "GUD" ti permetteranno di aprire altre visualizzazioni rilevanti per qualunque cosa tu stia tentando di eseguire il debug. (I frame sono finestre separate e "Windows" sono finestre in-frame)

Di solito per impostazione predefinita, un punto di interruzione è impostato all'avvio del programma, e puoi quindi navigare nel codice usando i pulsanti nella parte superiore la finestra o, se non si dispone di codice, è possibile personalizzare la visualizzazione per consentire lo smontaggio del file binario che si sta guardando.

I pulsanti nella parte superiore della finestra circondati da "{} "sono per il passaggio a livello di codice, mentre i pulsanti con" <> "nella loro icona servono per il debug a livello di istruzione. Quindi probabilmente vorrai concentrarti sulla sinistra se stai eseguendo il normale debug del codice e concentrarti maggiormente sulla destra se stai entrando nel vero nocciolo.

Inoltre, se ti perdi, questa icona:

È un intero libro che probabilmente può rispondere alle tue domande. L'unica volta che non esisterà in Emacs è se sei su Debian (Ubuntu va bene) e hai installato Emacs dai suoi repository. In tal caso sarà necessario installare " emacs<vesrsion>-common-non-dfsg " per ottenere i manuali. (Con " <version> " come cifre non decimali restituite da M-x version in Emacs)

La mia opinione è un po 'di parte ma, per il debug dell'assembler, il miglior "frontend" GDB disponibile è IDA (supporta la comunicazione con target GDB remoti). Per il debug del codice sorgente, tuttavia, consiglierei KDBG.

Anche a rischio di un grave downvoting, mi piacerebbe schierarmi con il semplice vecchio prompt gdb e sconsigliare un frontend GUI. Ho iniziato a imparare un uso più avanzato di GDB leggendo Art of Debugging alcuni anni fa. Descrive GDB e DDD così come Eclipse come frontend per GDB.

Certamente la maggior parte delle volte utilizzo Vim come IDE sul terminale e tmux (in precedenza screen con byobu ). Pertanto sto passando da un pannello all'altro nel mio multiplexer terminale per passare rapidamente dal codice al debugger. Il prompt di GDB - dopo alcune settimane di prova della TUI - ha davvero tutto ciò che ho sempre desiderato e dovresti tenere presente che puoi collegarti più volte allo stesso processo (quindi dare un'occhiata alla memoria nel modo in cui la descrivi).

Sembra che tutti i frontend siano un po 'indietro - nessuna sorpresa - e ha più senso fare i conti con il prompt di GDB e le sue sottigliezze e stranezze. Tieni presente che su una configurazione bare metal potrebbe essere l'unica cosa che hai. Quindi ha senso impararlo anche se trovi una GUI "decente" secondo i tuoi standard.

Le versioni più recenti di GDB supporteranno anche lo scripting Python e attraverso questo forniranno un set molto potente di strumenti per il debug, anche solo dalla riga di comando.

Se insisti assolutamente nell'usare un frontend GUI, consiglierei anche IDA Pro per il semplice motivo che ti offre un unico frontend per una varietà di debugger e devi impara (o personalizza) le sue scorciatoie solo una volta. Svantaggi: prezzo e flessibilità quando non si dispone di una licenza su una macchina particolare o non si ha modo di eseguire il tunneling a un server GDB ecc ...

Non sono a conoscenza di alcun frontend di GDB che accetti i comandi WinDbg. E posso solo sottolineare ancora una volta: raccoglierai comunque il frutto del tempo investito nell'apprendimento del GDB vanigliato. Non rifuggire dallo sforzo. Ci sono molte cose in WinDbg che sono specifiche per il modo in cui funziona Windows, il kernel di Windows e così via. GDB è molto più generico.

Vorrei suggerire DDD.

Se hai il codice sorgente, dovresti controllare QTCreator. Il suo debugger è simile a quello di Visual Studio, se lo conosci.

Non GUI ma un buon sostituto una volta che ci si abitua (e personalmente penso che sia più veloce per la maggior parte delle cose) -> https://github.com/gdbinit/Gdbinit.

Mi sono ricordato quando ho iniziato a invertire * nix e ho dovuto affrontare gdb per la prima volta. L'ho odiato e + gdbinit di mammon original mi ha salvato la giornata. In questi giorni preferisco gdb alla maggior parte dei debugger GUI.

Provalo :-)

Divulgazione completa: sono l'autore dello strumento.

Non mi piace molto DDD, è così anni '90 nella sua GUI.

Vorrei raccomandare KDBG, che è un frontend di KDE per gdb. Inoltre, potresti dare un'occhiata a Cgdb, che è un'estensione di curses per gdb.

Ultimamente mi sono imbattuto in Nemiver, sembra davvero promettente.

cgdb è anche un'ottima opzione se usi Vim.

cgdb condivide molti comandi con vim, come la ricerca regex e molti altri. Dalla home page di cgdb:

L'interfaccia della tastiera è modellata su vim, quindi gli utenti di vim dovrebbero sentirsi a casa usando cgdb.

Di solito uso Vim + gdb in modalità CLI durante la codifica, ecc. Ma a volte è preferibile una GUI.

Un'altra opzione, oltre a quelle menzionate, è Code :: Blocks. Utilizza GDB e CDB come back-end. Per GDB puoi selezionare AT&T, Intel o custom per lo smontaggio. Supporta la modalità mista e l'elenco delle istruzioni pure. Puoi impostarlo ulteriormente per valutare le variabili (nel codice) sotto il cursore ecc.

C'è solo una finestra di dump della memoria, ma puoi anche inserire comandi GDB grezzi in Riga di comando in basso che viene stampata sulla finestra - quindi ad es dump della memoria.

Ha una finestra separata per i registri della CPU, non sono modificabili direttamente, ma puoi impostare i valori dalla riga di comando menzionata, così come altri valori:

  set $ eax = 123set var xyz = 'q'  

L'immagine sotto lo mostra in azione con il debug del sorgente su un KVM (apri il link per visualizzarlo in dimensioni maggiori formato).

Un problema che ho avuto con esso sono alcuni bug della GUI ecc. quando lo eseguo su Ubuntu 12 - UB 12 ha la versione 10.10. Ma la compilazione e l'installazione della versione corrente, 12.11, è stata indolore.

Ad es. per l'installazione del percorso di installazione personalizzato (se la tua distribuzione non ha una versione aggiornata e desideri averle entrambe):

  - Scarica (SVN o versione) .- Unpack.- ./configure - -exec-prefix = / blahblah / codeblocks --prefix = / blahblah / codeblocks- make- sudo make install 2>&1 | tee my_install.log  

Questo articolo di Dr Dobbs mostra in dettaglio le GUI per il debug su SO Linux. Raccomando il Qt-Creator chiamato debug GDB basato su ambiente Linux. Ad ogni modo l'articolo esamina solo il debug del codice C ++, ma questo è sufficiente per mostrare le funzionalità di debug di GDB.

Raccomanderò UltraGDB, che è il frontend GUI GDB e un IDE leggero basato sulla tecnologia Eclipse.

È disponibile Affnic Debugger GUI. Non è gratuito ma esiste una versione lite. È disponibile per Windows, Linux & MacOS.

Dal sito web ufficiale,

Affinic Debugger GUI .aka. ADG, è progettato come un'interfaccia utente grafica per vari debugger. Questa build è specificatamente mirata su GDB, il debugger GNU. Con le finestre grafiche, ADG può liberare tutta la potenza dei debugger visualizzando più tipi di informazioni all'interno di una vista e manovrando i debugger con un semplice clic. ADG fornisce anche un terminale di comando integrato per consentire agli utenti di immettere direttamente il comando del debugger. ADG è disponibile su Linux / Windows / Mac OS X.

VisualStudio.Code ( VS.Code) funziona su Linux e ha un'estensione "Native Debug" che ti consente di utilizzare gdb. Ha un'interfaccia utente molto reattiva. È estremamente leggero sulle risorse. L'esperienza si avvicina in qualche modo a Visual Studio su Windows per gli sviluppatori C ++ (non esiste però una vista assembly). Le scorciatoie di debug principali sono le stesse predefinite (F5, Shift-F5, F10, F11).

L'installazione avviene con due clic (uno per installare VS.Code, l'altro per installare l'estensione) , ottimo per chi proviene da Windows Visual Studio e desidera essere produttivo fin da subito.

C'è Voltron, che è un'interfaccia utente estensibile del debugger Python che supporta LLDB, GDB, VDB e WinDbg / CDB (tramite PyKD) e funziona su macOS, Linux e Windows. Per i primi tre supporta x86, x86_64 e arm con anche il supporto arm64 per lldb mentre aggiunge anche il supporto powerpc per gdb.

L'autore ha anche scritto un plugin Binary Ninja per integrare Voltron - https : //github.com/snare/binjatron, che consente visualizzazioni sincronizzate.

Tieni presente che quanto segue si applica solo al debug del codice sorgente.

CLion è un IDE che utilizza gdb . Hai ancora la possibilità di digitare i comandi, ma molte funzionalità sono implementate senza problemi nella GUI come lo stepping, la visualizzazione delle variabili attualmente attive e l'impostazione di breakpoints . Ulteriori informazioni qui .

Puoi utilizzare GDBFrontend. Questo è un frontend GDB molto hackerabile.

Divulgazione completa: io sono lo sviluppatore.