Anstendig GUI for GDB

Jeg startet min egen gdb-frontend som heter gdbgui som er en server (i python) som lar deg få tilgang til en fullverdig frontend i nettleseren din .

Installer

pip install gdbgui --upgrade 

eller last ned på gdbgui.com

Fungerer på alle plattformer (Linux, macOS og Windows) og nettlesere med JavaScript.

Kjør

Bare skriv

gdbgui 

i terminalen din, og du r nettleser åpner en ny fane.

Funksjoner

• angi / fjerne brytepunkter
• vis kildekode, med valgfri innebygd maskinkode
• velg gjeldende ramme i stabel
• gå gjennom kildekode eller maskinkode
• opprett / utforsk variabler
• vis / velg tråder
• utforsk minne
• vis registre
• full gdb-terminalfunksjonalitet slik at du kan sende tradisjonelle gdb-kommandoer, og se gdb / dårligere programutgang
• layout inspirert av den fantastiske Chrome-feilsøkingen
• kompatibel med Mozillas RR, for omvendt feilsøking

Kommentarer

• Dette er virkelig noe godt arbeid. Designet kommer til kjernen i den gjennomsnittlige brukssaken. Jeg liker det. Den støtter også ekstern feilsøking (eller rettere, den støtter bruk av target remote host:port gdb-kommandoen. Pent gjort. Kanskje å legge til muligheten til å koble til en ekstern vert i menyen, ville være et hyggelig tillegg -på. Ville det være mulig å redusere ‘ registerstørrelsen? All informasjon er tilgjengelig, men (i det minste på ARM) kan du ‘ Ikke se alle registrene samtidig, så du må bla.
• Kommentarene her er ikke for individuell gdbgui støtte. Vennligst åpne en ny spørsmål på sx, eller bruk gdbgui-støttekanaler / bug tracker.

Selv om noen ikke gjør det For å ta vare på grensesnittet, er det verdt å nevne at GDB også har sin egen innebygde GUI (kalt TUI).

Du kan starte GDB i GUI-modus med kommandoen: gdb -tui

En rask referanse til TUI-kommandoer finner du her: http://beej.us/guide/bggdb/#qref

Jeg har generelt brukt Emacs GUD som en GDB-frontend.

Det er ikke for vanskelig å bruke, lar deg sette brytepunkter visuelt (eller om GDB-vinduet hvis du foretrekker det).

Den har flere forskjellige visninger som du kan få tilgang til fra en GDB-meny på toppnivå:

Det tillater også finesser som å la deg inspisere verdier ved å muse over dem:

For å kunne bruke den, må du først navigere til mappen til din binære med C-x C-f, deretter M-x gdb (That «s» Alt + X » , og skriv deretter «gdb«). Etter å ha gjort dette, kan du skrive en gdb-kommandolinje, eller bare trykke [Enter] for å godta standardverdien. Derfra skriver du bare «start» i gdb-vinduet med parametrene du vil overføre til programmet du feilsøker.

Etter det er du ganske gylden, men med bare en visning. Menyene øverst på skjermen under «GUD» lar deg åpne andre relevante visninger for hva du prøver å feilsøke.(Rammer er separate vinduer og «Windows» er vinduer i rammen)

Vanligvis settes det som standard et bruddpunkt ved programstart, og du kan deretter enten navigere i koden din ved hjelp av knappene øverst på vinduet, eller hvis du ikke har noen kode, kan du tilpasse visningen din slik at du kan gå gjennom en demontering av binæren du ser på.

Knappene øverst i vinduet omgitt av «{} «er for trinn på kodenivå, og knappene med» <> «i ikonet deres er for feilsøking på instruksjonsnivå. Så du vil sannsynligvis ønske å fokusere til venstre hvis du gjør vanlig kodedebugging, og fokusere mer på høyre hvis du kommer inn i den virkelige nitty-gritty.

Også, hvis du noen gang går deg vill, dette ikonet:

Det er en hele boka som sannsynligvis kan svare på spørsmålene dine. Den eneste gangen det ikke eksisterer i Emacs, er hvis du er på Debian (Ubuntu er bra) og installerte Emacs fra repos. I så fall må du installere «emacs<vesrsion>-common-non-dfsg» for å få manualene. (Med «<version>» som de ikke-desimale sifrene som returneres av M-x version i Emacs)

Kommentarer

• Dette er Spacemacs og ikke GNU Emacs, ikke sant?
• Nei. Dette er klart ‘ ol GNU Emacs, jeg har bare min utformet for å se slik ut. Ingenting jeg nevnte ovenfor er spesifikt for konfigurasjonen min. (Og faktisk er Spacemacs bare et sett med Emacs-konfigurasjoner også, men jeg har ingen anelse om det endrer GDB-bruk noe)
• At ‘ ikke lager Emacs. Hvilket operativsystem og hvilke pakker kjører du?
• Ser ut som om du har Power Line-pakken installert blant andre ting. emacswiki.org/emacs/PowerLine
• @mrbean Dette på Linux Mint og ja, jeg tror mitt Emacs-tema i 2013 var base16-i morgen med PowerLine (Fin anerkjennelse btw!)

Min mening er litt partisk, men for debugging assembler, er den beste GDB «frontend» der ute IDA (den støtter kommunikasjon med eksterne GDB-mål). For kildekode-feilsøking vil jeg imidlertid anbefale KDBG.

Kommentarer

• Jeg vil faktisk anbefale å bruke IDA ‘ s linux_server over ekstern GDB, den ‘ er mer i stand og raskere (siden den bruker binær protokoll og ikke tekstbasert en ).
• Begrunn din anbefaling. Svarene er skrevet ikke bare for OP, men for alle de andre som kan komme over dette i fremtiden.
• I utgangspunktet fordi du har all kraften til IDA (plugins, IDAPython scripting, kjent GUI,. ..) og er ikke bare en frontend for GDB.

Selv med fare for alvorlig nedstemning , Jeg vil gjerne gå med den vanlige gdb -prompten og anbefale mot en GUI-frontend. Jeg begynte å lære mer avansert bruk av GDB ved å lese Art of Debugging for noen år siden. Den beskriver GDB og DDD samt Eclipse som frontender til GDB.

Riktignok bruker jeg mest Vim som IDE på terminal og tmux (tidligere screen med byobu). Derfor bytter jeg mellom ruter i min terminalmultiplekser for å bytte raskt mellom kode og feilsøkingsprogram. GDB-ledeteksten – etter noen uker med å prøve TUI – har ikke reddet alt jeg noensinne har ønsket, og du må huske på at du kan knytte flere ganger til den samme prosessen (og derved se på minnet slik du beskriver det).

Det ser ut til at alle frontene henger etter litt – ingen overraskelse – og det er mer fornuftig å avtale GDB-ledeteksten og dens finesser og underlige ting. Husk at det kan være det eneste du har i et metallmontert oppsett. Dermed er det fornuftig å lære det selv om du finner en «anstendig» GUI etter dine egne standarder.

Nyere versjoner av GDB vil også støtte Python-skripting og gjennom det gi et veldig kraftig sett med verktøy for feilsøking, til og med bare fra kommandolinjen.

Hvis du absolutt insisterer på å bruke en GUI-frontend, vil jeg også anbefale IDA Pro av den enkle grunn at det gir deg en enkelt frontend for en rekke feilsøkingsprogrammer, og du må lære (eller tilpasse) snarveiene bare en gang. Ulemper: pris og fleksibilitet når du ikke har lisens på en bestemt maskin eller ingen måte å tunnelere til en GDB-server osv …

Jeg er ikke klar over noen frontend av GDB som godtar WinDbg-kommandoer. Og jeg kan bare understreke igjen: du vil høste frukten av tiden som er investert i å lære vanilje GDB uansett. Ikke vike unna innsatsen. Det er mange ting i WinDbg som er spesifikke for måten Windows fungerer på, Windows-kjernen fungerer og så videre. GDB er mye mer generisk.

Jeg vil foreslå DDD .

Hvis du har kildekode, bør du sjekke ut QTCreator . Feilsøkingsprogrammet ligner Visual Studio, hvis du er kjent med det.

Kommentarer

• I ‘ har brukt DDD og var ikke ‘ en fan. Jeg ‘ Sjekk ut QtCreator skjønt, takk!
• DDD er flott for visning av datastrukturer, du kan legge dem ut på et tavle (et lyst bord av slag ). Derfor data-display-debugger.
• DDD ser rart og utdatert ved første øyekast, men det ‘ er veldig kraftig.

Ikke GUI, men en god erstatning når du først er vant til det (og personlig tror jeg det er raskere for de fleste ting ) -> https://github.com/gdbinit/Gdbinit .

Jeg husket da jeg startet * nix reversering og jeg hadde å møte gdb for første gang. Hatet det og + mammon original «s gdbinit reddet dagen min. I disse dager foretrekker jeg gdb fremfor de fleste GUI-feilsøkere.

Prøv det 🙂

Full beskrivelse: Jeg er forfatteren av verktøyet.

Kommentarer

• Du bør skrive en informasjon om at Gdbinit er en programvare du ‘ vedlikeholder …
• Så? Det ‘ er gratis, tilgjengelig for alle. Prøver ikke akkurat å selge noe her. Jøss …!
• @ fg- Det kan fremdeles være noe reklame som ikke er basert på erfaring, men utelukkende på det faktum at du skrev det verktøyet.
• Så du kan ‘ Vil du ikke annonsere for nyttige verktøy som løser problemer og må vente på at andre skal gjøre det? At ‘ er en veldig merkelig tenkemodus for en problemløser » fellesskap «.
• @ fG- Vennligst les FAQ: reverseengineering.stackexchange.com/faq#promotion

Jeg liker ikke DDD, det er så 90 «i GUI.

Jeg vil anbefaler KDBG, som er en KDE-frontend til gdb. Dessuten vil du kanskje se på Cgdb, som er en forbannelseutvidelse for gdb.

I det siste kom jeg over Nemiver , det ser veldig lovende ut.

Kommentarer

• Fungerer KDBG bra for demontering og feilsøking uten kilde også? Skjermbildene deres viste bare kildekoden.
• Jeg vet ikke ‘, aldri prøvd det før …
• » it ‘ s så 90 ‘ s i den ‘ s GUI » … mer som 80 ‘ s
• Er utseendet på GUI den eneste ulempen?

cgdb er også et flott alternativ hvis du bruker Vim.

cgdb deler mange kommandoer med vim, for eksempel regex search og mange andre. Fra cgdb-hjemmesiden:

Tastaturgrensesnittet er modellert etter vim, så vim-brukere skal føle seg hjemme ved hjelp av cgdb.

Jeg bruker vanligvis Vim + gdb i CLI-modus når jeg koder osv. Men noen ganger er en GUI å foretrekke.

Et annet alternativ, ved siden av de nevnte, er Code :: Blocks. Den bruker GDB og CDB som back-end. For GDB kan du velge AT & T, Intel eller tilpasset for demontering. Den støtter blandet modus samt rene instruksjoner. Du kan videre sette det opp for å evaluere variabler (i kode) under markør osv.

Det er bare ett minnedump-vindu, men du kan i tillegg legge inn rå GDB-kommandoer i Kommandolinje nederst som blir skrevet ut til vinduet – altså f.eks memory dumps.

Den har et eget vindu for CPU-registre, de kan ikke redigeres direkte, men du kan angi verdier ved nevnte kommandolinje, samt andre verdier:

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

Bildet nedenfor viser det i aksjon med kildedebugging på en KVM (Åpne lenke for å se den i større format).

Et problem jeg har hatt med det er noen GUI-feil osv. når jeg kjører det på Ubuntu 12 – UB 12 har versjon 10.10. Men en kompilering og installasjon av nåværende utgivelse , 12.11, var smertefri.

F.eks. for tilpasset installasjonsstiinstallasjon (Hvis distribusjonen din ikke har oppdatert versjon og du vil ha begge deler):

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

Denne Dr Dobbs-artikkelen viser i detalj GUIer for feilsøking på Linux OS. Jeg anbefaler Qt-Creator kalt GDB debug basert på Linux-miljø.Uansett vurderer artikkelen bare feilsøking C ++ – kode, men det er nok til å vise frem GDBs feilsøkingsfunksjoner.

Jeg vil anbefale UltraGDB , som er GDB GUI-frontend og lett IDE basert på Eclipse-teknologi.

VisualStudio.Code ( VS.Code ) kjører på Linux og har en «Native Debug» -utvidelse som lar deg bruke gdb. Den har veldig responsiv brukergrensesnitt. Den er ekstremt lett på ressurser. Opplevelsen tilnærmer noe Visual Studio på Windows for C ++ -utviklere (det er ingen monteringsvisning skjønt). Hovedfeilsøkingssnarveiene er de samme ut av esken (F5, Shift-F5, F10, F11).

Installasjon er to-klikk (ett for å installere VS.Code, det andre for å installere utvidelsen), flott for noen som kommer fra Windows Visual Studio og ønsker å være produktive med en gang.

Der «s Voltron , som er et utvidbart Python-feilsøkingsgrensesnitt som støtter LLDB, GDB, VDB , og WinDbg / CDB (via PyKD) og kjører på macOS, Linux og Windows. For de tre første støtter den x86, x86_64 og arm med jevn arm64-støtte for lldb mens den legger til jevn powerpc-støtte for gdb.

Forfatteren skrev også et Binary Ninja-plugin for å integrere Voltron – https://github.com/snare/binjatron – som tillater synkroniserte visninger.