Anstændigt GUI til GDB

Jeg startede min egen gdb frontend kaldet gdbgui hvilket er en server (i python), der giver dig adgang til en fuldt udstyret frontend i din browser .

Installer

pip install gdbgui --upgrade 

eller download på gdbgui.com

Fungerer på alle platforme (Linux, macOS og Windows) og browsere med JavaScript.

Kør

Skriv bare

gdbgui 

i din terminal, og du r browser åbner en ny fane.

Funktioner

• indstil / fjern breakpoints
• se sourcecode med valgfri integreret maskinkode
• vælg den aktuelle ramme i stakken
• trin igennem kildekoden eller maskinkoden
• opret / udforsk variabler
• vis / vælg tråde
• udforsk hukommelse
• se registre
• fuld gdb-terminalfunktionalitet, så du kan sende traditionelle gdb-kommandoer og se gdb / inferior programoutput
• layout inspireret af den fantastiske Chrome-fejlfindingsprogram
• kompatibel med Mozillas RR, til omvendt fejlretning

Kommentarer

• Dette er virkelig noget godt arbejde. Designet kommer til kernen i den gennemsnitlige brugssag. Jeg kan lide det. Det understøtter også fjernfejlfinding (eller rettere det understøtter brug af target remote host:port gdb-kommandoen. Pænt gjort. Måske at tilføje muligheden for at oprette forbindelse til en ekstern vært i menuen ville være en god tilføjelse Ville det være muligt at nedskalere ‘ registerstørrelsen? Alle oplysninger er tilgængelige, men (i det mindste på ARM) kan du ‘ Se ikke alle registre på én gang, så du skal rulle.
• Kommentarerne her er ikke til individuel gdbgui support. Åbn en ny spørgsmål på sx, eller brug gdbgui supportkanaler / bug tracker.

Selvom nogle mennesker ikke gør det For at passe på dens grænseflade er det værd at nævne, at GDB også har sin egen indbyggede GUI (kaldet TUI).

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

En hurtig henvisning til TUI-kommandoer kan findes her: http://beej.us/guide/bggdb/#qref

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

Det er ikke for svært at bruge, giver dig mulighed for at indstille breakpoints visuelt (eller om GDB-vinduet, hvis du foretrækker det).

Det har flere forskellige visninger, som du kan få adgang til fra en GDB-menu på øverste niveau:

Det tillader også lækkerier som at lade dig inspicere værdier ved at muse over dem:

For at bruge det skal du først navigere til mappen til din binære med C-x C-f, derefter M-x gdb (At “s” Alt + X ” og derefter skrive “gdb“). Når du har gjort dette, kan du skrive en gdb-kommandolinje eller bare trykke på [Enter] for at acceptere dens standard. Derfra skriver du bare “start” i gdb-vinduet med de parametre, du vil overføre til det program, du debugger.

Derefter er du stort set gylden, men med kun en visning. Menuerne øverst på skærmen under “GUD” giver dig mulighed for at åbne andre relevante visninger for det, du prøver at fejle.(Rammer er separate vinduer, og “Windows” er rammer i rammen)

Normalt indstilles som standard et brudpunkt ved programstart, og du kan derefter enten navigere i din kode ved hjælp af knapperne øverst på vinduet, eller hvis du ikke har nogen kode, kan du tilpasse din visning, så du kan gå gennem en adskillelse af den binære, du ser på.

Knapperne øverst i vinduet omgivet af “{} “er til trin på kodeniveau, og knapperne med” <> “i deres ikon er til fejlfinding på instruktionsniveau. Så du vil sandsynligvis ønske at fokusere til venstre, hvis du laver normal kodefejlfinding, og fokusere mere på højre, hvis du kommer ind i den virkelige nitty-gritty.

Også hvis du nogensinde går vild, dette ikon:

Det er en hele bogen, der sandsynligvis kan besvare dine spørgsmål. Den eneste gang det ikke findes i Emacs, er hvis du er på Debian (Ubuntu er fint) og installerede Emacs fra dets repos. I så fald skal du installere “emacs<vesrsion>-common-non-dfsg” for at få vejledningerne. (Med “<version>” som de ikke-decimale cifre returneret af M-x version i Emacs)

Kommentarer

• Dette er Spacemacs og ikke GNU Emacs, ikke?
• Nej. Dette er almindeligt ‘ ol GNU Emacs, jeg har bare min stil til at se sådan ud. Intet jeg nævnte ovenfor er specifikt for min konfiguration. (Og faktisk er Spacemacs kun et sæt Emacs-konfigurationer, men jeg har ingen anelse om det ændrer GDB-brug nogen)
• At ‘ ikke indeholder Emacs. Hvilket operativsystem og hvilke pakker kører du?
• Det ser ud til, at du har Power Line-pakken installeret blandt andre ting. emacswiki.org/emacs/PowerLine
• @mrbean Dette på Linux Mint og ja, jeg tror mit Emacs-tema i 2013 var base16-i morgen med PowerLine (Dejlig anerkendelse btw!)

Min mening er lidt forudindtaget, men til debugging assembler er den bedste GDB “frontend” derude IDA (den understøtter kommunikation med eksterne GDB-mål). Til kildekodefejlfinding vil jeg dog anbefale KDBG.

Kommentarer

• Jeg vil faktisk anbefale at bruge IDA ‘ s linux_server over ekstern GDB, er det ‘ mere kapabel og hurtigere (da den bruger binær protokol og ikke tekstbaseret en ).
• Begrund din anbefaling. Svarene er skrevet ikke kun til OP, men til alle de andre mennesker, der muligvis støder på dette i fremtiden.
• Grundlæggende fordi du har al magt fra IDA (plugins, IDAPython scripting, kendt GUI,. ..) og er ikke kun en frontend for GDB.

Selv med risiko for alvorlig nedstemning , Jeg vil gerne sidde med den almindelige gdb -prompt og anbefale mod en GUI-frontend. Jeg begyndte at lære mere avanceret brug af GDB ved at læse Art of Debugging for nogle år siden. Den beskriver GDB og DDD samt Eclipse som frontfront til GDB.

Ganske vist bruger jeg Vim som min IDE på terminal og tmux (tidligere screen med byobu). Derfor skifter jeg mellem ruder i min terminalmultiplexer til hurtigt at skifte mellem kode og fejlretning. GDB-prompten – efter nogle ugers forsøg på TUI – har inde redigeret alt, hvad jeg nogensinde har ønsket, og du skal huske på, at du kan vedhæfte flere gange til den samme proces (og derved se på hukommelsen, som du beskriver det).

Det ser ud til, at alle frontender hænger bagefter lidt – ingen overraskelse – og det giver mere mening at komme overens med GDB-prompten og dens finesser og underlige egenskaber. Husk, at det på en bare-metal-opsætning kan være det eneste, du har. Det er således fornuftigt at lære det, selvom du finder en “anstændig” GUI efter dine egne standarder.

Nyere versioner af GDB vil også understøtte Python-scripting og derved give et meget kraftigt sæt værktøjer til fejlfinding, selv bare fra kommandolinjen.

Hvis du absolut insisterer på at bruge en GUI-frontend, vil jeg også anbefale IDA Pro af den enkle grund, at det giver dig en enkelt frontend til en række debuggere, og du bliver nødt til Lær (eller tilpas) genveje kun en gang. Ulemper: pris og fleksibilitet, når du ikke har licens på en bestemt maskine eller ingen måde at tunnelere til en GDB-server osv …

Jeg er ikke opmærksom på nogen frontend på GDB der accepterer WinDbg-kommandoer. Og jeg kan kun understrege igen: Du høster frugten af den tid, der er investeret i at lære vanille GDB alligevel. Gå ikke væk fra indsatsen. Der er masser af ting i WinDbg, der er specifikke for den måde, hvorpå Windows fungerer, Windows-kernen fungerer osv. GDB er meget mere generisk.

Jeg vil gerne foreslå DDD .

Hvis du har kildekode, skal du tjekke QTCreator . Dens debugger ligner Visual Studios, hvis du er fortrolig med det.

Kommentarer

• I ‘ har brugt DDD og var ikke ‘ en fan. Jeg ‘ Jeg skal dog tjekke QtCreator, tak!
• DDD er fantastisk til visning af datastrukturer, du kan lægge dem ud på et bræt (en slags lys tabel) ). Derfor data-display-debugger.
• DDD ser underligt og forældet ud ved første øjekast, men det ‘ er virkelig stærkt.

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

Jeg huskede, da jeg startede * nix reversering, og jeg havde at møde gdb for første gang. Hadede det og + mammon original “s gdbinit reddede min dag. I disse dage foretrækker jeg gdb fremfor de fleste GUI-debuggere.

Giv det en chance 🙂

Fuld offentliggørelse: Jeg er forfatter til værktøjet.

Kommentarer

• Du skal skrive en oplysning om, at Gdbinit er en software, du ‘ vedligeholder …
• Så? Det ‘ er gratis, tilgængeligt for alle. Prøver ikke ligefrem at sælge noget her. Jøss …!
• @ fg- Det kan stadig være noget reklame, der ikke er baseret på erfaring, men udelukkende på det faktum, at du skrev det værktøj.
• Så du kan ‘ t annoncere for dine nyttige værktøjer, der løser problemer og er nødt til at vente på, at andre gør det? At ‘ er en virkelig underlig tænkningstilstand til en problemløser ” samfund “.
• @ fG- læs venligst FAQ: reverseengineering.stackexchange.com/faq#promotion

Jeg kan ikke godt lide DDD, det er så 90 “i GUIet.

Jeg vil kan lide at anbefale KDBG, som er en KDE-frontend til gdb. Desuden vil du måske se på Cgdb, som er en forbandelsesudvidelse for gdb.

For nylig stødte jeg på Nemiver , det ser virkelig lovende ud.

Kommentarer

• Fungerer KDBG også godt til adskillelse og fejlretning uden kilde? Deres skærmbilleder viste kun kildekode.
• Jeg ved ikke ‘, aldrig prøvet det før …
• ” it ‘ s så 90 ‘ s i det ‘ s GUI ” … mere som 80 ‘ s
• Er udseendet af GUI den eneste ulempe?

cgdb er også en god mulighed, hvis du bruger Vim.

cgdb deler mange kommandoer med vim, såsom regex-søgning og mange andre. Fra cgdb-startsiden:

Tastaturgrænsefladen er modelleret efter vim, så vim-brugere skal føle sig hjemme ved hjælp af cgdb.

Jeg bruger normalt Vim + gdb i CLI-tilstand ved kodning osv. Men nogle gange er en GUI foretrækkes.

En anden mulighed udover de nævnte er Code :: Blocks. Det bruger GDB og CDB som back-end. For GDB kan du vælge AT & T, Intel eller custom til adskillelse. Det understøtter blandet tilstand samt rene instruktioner. Du kan yderligere indstille det til at evaluere variabler (i kode) under markør osv.

Der er kun et hukommelsesdumpvindue, men du kan desuden indtaste rå GDB-kommandoer i Kommandolinje i bunden, som bliver udskrevet til vinduet – således f.eks memory dumps.

Det har et separat vindue til CPU-registre, de kan ikke redigeres direkte, men du kan indstille værdier ved den nævnte kommandolinje såvel som andre værdier:

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

Billedet nedenfor viser det i aktion med kildedebugging på en KVM (Åbn link for at se det i større format).

Et problem, jeg har haft med det, er nogle GUI-fejl osv., når jeg kører det på Ubuntu 12 – UB 12 har version 10.10. Men en kompilering og installation af nuværende udgivelse , 12.11, var smertefri.

F.eks. til installation af brugerdefineret installationssti (Hvis din distribution ikke har en opdateret version, og du vil have begge dele):

- 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-artikel viser detaljerede GUIer til debugging på Linux OS. Jeg anbefaler Qt-Creator kaldet GDB debug baseret på Linux-miljø.Under alle omstændigheder gennemgår artiklen kun debugging C ++ – kode, men det er nok til at vise GDBs debugging-funktioner.

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

VisualStudio.Code ( VS.Code ) kører på Linux og har en “Native Debug” -udvidelse, der lader dig bruge gdb. Den har meget lydhør brugergrænseflade. Det er ekstremt let på ressourcer. Oplevelsen tilnærmer noget Visual Studio på Windows til C ++ – udviklere (der er dog ingen samlevisning). De vigtigste genvejsfejlgenveje er de samme ud af kassen (F5, Shift-F5, F10, F11).

Installation er to-klik (det ene for at installere VS.Code, det andet for at installere udvidelsen), fantastisk til nogen, der kommer fra Windows Visual Studio og ønsker at være produktive med det samme.

Der er “s Voltron , som er en udvidelig Python debugger UI, der understøtter LLDB, GDB, VDB og WinDbg / CDB (via PyKD) og kører på macOS, Linux og Windows. For de første tre understøtter den x86, x86_64 og arm med jævn arm64-understøttelse til lldb, mens den tilføjer jævn powerpc-understøttelse til gdb.

Forfatteren skrev også et binært Ninja-plugin for at integrere Voltron – https://github.com/snare/binjatron – som tillader synkroniserede visninger.