Domanda:
GUI decente per GDB
mrduclaw
2013-03-30 07:30:22 UTC
view on stackexchange narkive permalink

Imparare i comandi GDB è nella mia lista dei desideri, ma nel frattempo esiste un debugger grafico per piattaforme * nix che accetta i comandi Windbg e ha funzionalità simili? Ad esempio, la capacità di far emergere più finestre di memoria modificabili, smontare automaticamente intorno a un'area mentre si cammina, impostare il sapore di smontaggio e avere una finestra con registri con valori modificabili?

@AshRj ah, capisco cosa intendi ora. Errore mio, scuse.
[Voltron] (http://ho.ax/posts/2013/06/voltron-a-hacky-ui-for-gdb/) è totalmente nuovo ma sembra promettere bene (non l'ho ancora testato).
Su SO: http://stackoverflow.com/questions/79023/is-there-a-c-gdb-gui-for-linux
Diciassette risposte:
#1
+59
cs01
2016-09-26 05:26:05 UTC
view on stackexchange narkive permalink

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 .

gdbgui screenshot

  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
Questo è davvero un buon lavoro. Il design arriva al centro del caso d'uso medio. Mi piace. Supporta anche il debug remoto (o, piuttosto, supporta l'uso del comando `target remote host: port` gdb. Ben fatto. Forse aggiungere la possibilità di connettersi a un host remoto nel menu sarebbe un bel add-on. Lo farebbe è possibile ridurre la dimensione del 'registro`? Tutte le informazioni sono disponibili, ma (almeno su ARM) non puoi vedere tutti i registri contemporaneamente, quindi devi scorrere.
I commenti qui non sono per il supporto individuale di `gdbgui`. Apri una nuova domanda su sx o utilizza i canali di supporto / bug tracker di gdbgui.
#2
+46
mncoppola
2013-03-30 08:09:56 UTC
view on stackexchange narkive permalink

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

#3
+32
Archenoth
2013-04-04 08:50:08 UTC
view on stackexchange narkive permalink

In genere ho usato Emacs GUD come frontend GDB.

GDB support in Emacs

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:

GUD Views

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

Mouseover values

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:

GUD info

È 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)

Questo è Spacemacs e non GNU Emacs, giusto?
No. Questo è semplice GNU Emacs, ho solo il mio stile per assomigliare a questo. Niente di quello che ho menzionato sopra è specifico per la mia configurazione. (E in realtà, anche Spacemacs è solo un insieme di configurazioni di Emacs, ma non ho idea se cambia l'utilizzo di GDB)
#4
+27
joxeankoret
2013-03-30 15:12:24 UTC
view on stackexchange narkive permalink

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.

In realtà consiglierei di usare il `linux_server` di IDA su GDB remoto, è più capace e più veloce (dato che usa il protocollo binario e non quello basato su testo).
Per favore giustifica la tua raccomandazione. Le risposte sono scritte non solo per il PO, ma per tutte le altre persone che potrebbero incontrarlo in futuro.
Fondamentalmente perché hai tutta la potenza di IDA (plugin, script IDAPython, GUI conosciuta, ...) e non è solo un frontend per GDB.
#5
+21
0xC0000022L
2013-04-02 05:58:50 UTC
view on stackexchange narkive permalink

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.

#6
+18
omghai2u
2013-03-30 07:39:53 UTC
view on stackexchange narkive permalink

Vorrei suggerire DDD.

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

Ho usato "DDD" e non ero un fan. Però controllerò QtCreator, grazie!
DDD è ottimo per visualizzare strutture di dati, puoi disporli su una lavagna (una sorta di tavolo luminoso). Quindi data-display-debugger.
DDD a prima vista sembra strano e obsoleto, ma è davvero potente.
#7
+11
fG-
2013-04-01 19:42:21 UTC
view on stackexchange narkive permalink

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.

Dovresti scrivere una dichiarazione che Gdbinit è un software che stai mantenendo ...
Così? È gratuito, disponibile per chiunque. Non esattamente cercando di vendere qualcosa qui. Geez ...!
@fg- Potrebbe trattarsi ancora di pubblicità che non si basa sull'esperienza ma esclusivamente sul fatto che hai scritto quello strumento.
Quindi non puoi pubblicizzare i tuoi strumenti utili che risolvono problemi e devi aspettare che altri lo facciano? Questa è una modalità di pensiero davvero strana per una "comunità" di risolutori di problemi.
@fG- si prega di leggere le FAQ: http://reverseengineering.stackexchange.com/faq#promotion
#8
+10
Mellowcandle
2013-03-30 12:42:53 UTC
view on stackexchange narkive permalink

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.

KDBG funziona bene anche per il disassemblaggio e il debug senza sorgente? I loro screenshot mostravano solo il codice sorgente.
Non lo so, non l'ho mai provato prima ...
"è così anni '90 nella sua GUI" ... più come anni '80
L'aspetto della GUI è l'unico svantaggio?
#9
+7
jlhonora
2013-05-08 21:15:02 UTC
view on stackexchange narkive permalink

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.

#10
+5
Runium
2013-06-22 04:54:49 UTC
view on stackexchange narkive permalink

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  

Code::Blocks with GDB

#11
+4
R.Chatsiri
2013-06-26 09:21:51 UTC
view on stackexchange narkive permalink

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.

#12
+3
Xiao Ming
2015-06-12 05:12:53 UTC
view on stackexchange narkive permalink

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

#13
+3
0xec
2015-06-12 21:11:55 UTC
view on stackexchange narkive permalink

È 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.

#14
+3
Sergiy Migdalskiy
2018-02-10 08:31:58 UTC
view on stackexchange narkive permalink

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.

#15
+2
atdre
2016-09-05 01:57:32 UTC
view on stackexchange narkive permalink

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.

#16
+2
BullyWiiPlaza
2017-01-17 14:39:06 UTC
view on stackexchange narkive permalink

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 .

#17
+1
Oğuzhan Eroğlu
2020-01-22 20:43:11 UTC
view on stackexchange narkive permalink

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

Divulgazione completa: io sono lo sviluppatore.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...