Anständigt GUI för GDB

Jag startade min egen gdb-frontend som heter gdbgui vilket är en server (i python) som låter dig komma åt en fullständig frontend i din webbläsare .

Installera

pip install gdbgui --upgrade 

eller ladda ner på gdbgui.com

Fungerar på alla plattformar (Linux, macOS och Windows) och webbläsare med JavaScript.

Kör

Skriv bara

gdbgui 

i din terminal och du r webbläsare öppnar en ny flik.

Funktioner

• ställa in / ta bort brytpunkter
• visa källkod, med valfri inbyggd maskinkod
• välj aktuell ram i stapel
• steg igenom källkod eller maskinkod
• skapa / utforska variabler
• visa / välj trådar
• utforska minne
• visa register
• full gdb-terminalfunktionalitet så att du kan skicka traditionella gdb-kommandon och visa gdb / sämre programutgång
• layout inspirerad av den fantastiska Chrome-felsökaren
• kompatibel med Mozillas RR, för omvänd felsökning

Kommentarer

• Det här är verkligen ett bra arbete. Designen kommer till kärnan i det genomsnittliga användningsfallet. Jag gillar det. Det stöder också fjärrfelsökning (eller snarare stöder det att använda kommandot target remote host:port gdb. Snyggt gjort. Att lägga till möjligheten att ansluta till en fjärrvärd i menyn skulle vara ett trevligt tillägg -on. Skulle det vara möjligt att minska ’ registerstorleken? All information är tillgänglig, men (åtminstone på ARM) kan du ’ Se inte alla register samtidigt, så du måste bläddra.
• Kommentarerna här är inte för individuellt gdbgui support. Öppna ett nytt fråga på sx, eller använd gdbgui supportkanaler / bug tracker.

Även om vissa människor inte gör det För att ta hand om dess gränssnitt är det värt att nämna att GDB också har en egen inbyggd GUI (kallad TUI).

Du kan starta GDB i GUI-läge med kommandot: gdb -tui

En snabb hänvisning till TUI-kommandon kan hittas här: http://beej.us/guide/bggdb/#qref

Jag har i allmänhet använt Emacs GUD som en GDB-frontend.

Det är inte för svårt att använda, låter dig ställa in brytpunkter visuellt (eller om GDB-fönstret om du föredrar det).

Den har flera olika vyer som du kan komma åt från en GDB-meny på högsta nivå:

Det tillåter också finesser som att låta dig inspektera värden genom att musa över dem:

För att kunna använda det måste du först navigera till mappen för din binära med C-x C-f, sedan M-x gdb (That ”s” Alt + X ” och sedan skriva ”gdb”). Efter att ha gjort detta kan du skriva en gdb-kommandorad eller bara trycka på [Enter] för att acceptera dess standard. Därifrån skriver du bara ”start” i gdb-fönstret med de parametrar du vill skicka till programmet du felsöker.

Därefter är du ganska mycket gyllene, men med bara en vy. Menyerna längst upp på skärmen under ”GUD” låter dig öppna andra relevanta vyer för vad du försöker felsöka.(Ramar är separata fönster och ”Windows” är ramar i fönstret)

Vanligtvis är som standard en brytpunkt inställd vid programstart, och du kan antingen navigera i din kod med knapparna högst upp på fönstret, eller om du inte har någon kod kan du anpassa din vy så att du kan gå igenom en demontering av det binära du tittar på.

Knapparna längst upp i fönstret omgivna av ”{} ”är för stegnivå på kodnivå, och knapparna med” <> ”i deras ikon är för felsökning på instruktionsnivå. Så du kommer antagligen vilja fokusera på vänster om du gör normal kodfelsökning och fokusera mer på höger om du går in i den riktiga nitty-gritty.

Om du någonsin går vilse, den här ikonen:

Det är en hela boken som sannolikt kan svara på dina frågor. Den enda gången det inte finns i Emacs är om du är på Debian (Ubuntu är bra) och installerade Emacs från sina repor. I så fall måste du installera ”emacs<vesrsion>-common-non-dfsg” för att få handböckerna. (Med ”<version>” som de icke-decimala siffrorna som returneras av M-x version i Emacs)

Kommentarer

• Det här är Spacemacs och inte GNU Emacs eller hur?
• Nej. Detta är klart ’ ol GNU Emacs, jag har bara min utformad så att den ser ut så här. Inget jag nämnde ovan är specifikt för min konfiguration. (Och faktiskt är Spacemacs bara en uppsättning Emacs-konfigurationer också, men jag har ingen aning om det ändrar GDB-användning någon)
• Att ’ inte har Emacs. Vilket operativsystem och paket kör du?
• Ser ut som om du har Power Line-paketet installerat bland andra saker. emacswiki.org/emacs/PowerLine
• @mrbean Detta på Linux Mint och ja, jag tror att mitt Emacs-tema 2013 var base16-imorgon med PowerLine (Trevligt erkännande btw!)

Min åsikt är lite partisk, men för felsökning av samlare är den bästa GDB-”frontend” där ute IDA (den stöder kommunikation med fjärr-GDB-mål). För källkodfelsökning rekommenderar jag dock KDBG.

Kommentarer

• Jag rekommenderar faktiskt att använda IDA ’ s linux_server över fjärr-GDB, det ’ är mer kapabelt och snabbare (eftersom det använder binärt protokoll och inte textbaserat ).
• Motivera din rekommendation. Svaren skrivs inte bara för OP utan även för alla andra människor som kan stöta på detta i framtiden.
• I grund och botten för att du har all kraft från IDA (plugins, IDAPython-skript, känd GUI,. ..) och är inte bara en frontend för GDB.

Även med risk för allvarlig nedröstning , Jag skulle vilja gå med den vanliga gdb -prompten och rekommendera mot en GUI-frontend. Jag började lära mig mer avancerad användning av GDB genom att läsa Art of Debugging för några år sedan. Det beskriver GDB och DDD samt Eclipse som frontfront till GDB.

Visserligen använder jag Vim som min IDE på terminal och tmux (tidigare screen med byobu). Därför byter jag mellan rutor i min terminalmultiplexer för att växla snabbt mellan kod och felsökare. GDB-prompten – efter några veckors försök med TUI – har inte redigerat allt jag någonsin önskat och du bör komma ihåg att du kan koppla flera gånger till samma process (därigenom ta en titt på minnet som du beskriver det.).

Det verkar som om alla frontendar ligger efter lite – ingen överraskning – och det är vettigare att komma överens med GDB-prompten och dess finesser och konstigheter. Tänk på att det i en ren metallinstallation kan vara det enda du har. Således är det vettigt att lära sig det även om du hittar en ”anständig” GUI enligt dina egna standarder.

Nyare versioner av GDB stöder också Python-skript och därmed ger en mycket kraftfull uppsättning verktyg att felsöka, till och med bara från kommandoraden.

Om du absolut insisterar på att använda en GUI-frontend, skulle jag också rekommendera IDA Pro av den enkla anledningen att det ger dig en enda frontend för en mängd olika debuggare och du måste lära sig (eller anpassa) dess genvägar bara en gång. Nackdelar: pris och flexibilitet när du inte har licens på en viss maskin eller inget sätt att tunnla till en GDB-server etc …

Jag känner inte till någon frontend på GDB som accepterar WinDbg-kommandon. Och jag kan bara betona igen: du kommer att skörda frukten av den tid som investerats i att lära dig vanilj GDB ändå. Vik inte undan ansträngningen. Det finns gott om saker i WinDbg som är specifika för hur Windows fungerar, Windows-kärnan fungerar och så vidare. GDB är mycket mer generiskt.

Jag skulle vilja föreslå DDD .

Om du har källkod bör du kolla in QTCreator . Dess felsökare liknar Visual Studio, om du känner till det.

Kommentarer

• I ’ har använt DDD och var inte ’ en fläkt. Jag ’ Men kolla in QtCreator, tack!
• DDD är utmärkt för att visa datastrukturer, du kan lägga ut dem på ett bräde (ett ljust bord av slag ). Därav data-display-debugger.
• DDD ser konstig och inaktuell vid första anblicken, men den ’ är riktigt kraftfull.

Inte GUI men en bra ersättning när du väl är van vid det (och personligen tycker jag att det är snabbare för de flesta saker ) -> https://github.com/gdbinit/Gdbinit .

Jag kom ihåg när jag började * nix backa och jag hade att möta gdb för första gången. Hatade det och + mammons original gdbinit räddade min dag. Dessa dagar föredrar jag gdb framför de flesta GUI-felsökare.

Testa 🙂

Fullständig information: Jag är författaren till verktyget.

Kommentarer

• Du bör skriva ett meddelande om att Gdbinit är en programvara som du ’ underhåller …
• Så? Det ’ är gratis, tillgängligt för alla. Försöker inte precis sälja någonting här. Hej …!
• @ fg- Det kan fortfarande vara lite reklam som inte bygger på erfarenhet utan bara på det faktum att du skrev verktyget.
• Så du kan ’ t annonsera om dina användbara verktyg som löser problem och måste vänta på att andra ska göra det? Att ’ är något riktigt konstigt tänkande för en problemlösare ” community ”.
• @ fG- läs FAQ: reverseengineering.stackexchange.com/faq#promotion

Jag gillar inte riktigt DDD, det är så 90 ”i det GUI.

Jag skulle vilja rekommenderar gärna KDBG, som är en KDE-frontend till gdb. Dessutom kanske du vill titta på Cgdb, vilket är ett förbannelseförlängning för gdb.

På senare tid stötte jag på Nemiver , det ser väldigt lovande ut.

Kommentarer

• Fungerar KDBG bra för demontering och felsökning utan källa också? Deras skärmdumpar visade bara källkod.
• Jag vet inte ’, aldrig testat det förr …
• ” it ’ s så 90 ’ s i det ’ s GUI ” … mer som 80 ’ s
• Är utseendet på GUI den enda nackdelen?

cgdb är också ett bra alternativ om du använder Vim.

cgdb delar många kommandon med vim, till exempel regex-sökning och många andra. Från cgdb-hemsidan:

Tangentbordsgränssnittet är modellerat efter vim, så vim-användare ska känna sig hemma med cgdb.

Jag använder vanligtvis Vim + gdb i CLI-läge vid kodning etc. Men ibland är ett GUI att föredra.

Ett annat alternativ, förutom de som nämns, är Code :: Blocks. Den använder GDB och CDB som back-end. För GDB kan du välja AT & T, Intel eller anpassad för demontering. Den stöder blandat läge samt rena instruktioner. Du kan också ställa in det för att utvärdera variabler (i kod) under markören etc.

Det finns bara ett minnesdumpfönster, men du kan dessutom ange rå GDB-kommandon i Kommandorad längst ner som skrivs ut till fönster – alltså t.ex. minnesdumpar.

Det har ett separat fönster för CPU-register, de är inte direkt redigerbara, men du kan ställa in värden med nämnda kommandorad, liksom andra värden:

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

Bilden nedan visar den i aktion med källfelsökning på en KVM (Öppna länk för att visa den i större format).

Ett problem jag har haft med det är några GUI-buggar etc. när jag kör det på Ubuntu 12 – UB 12 har version 10.10. Men en kompilering och installation av nuvarande version , 12.11, var smärtfri.

Exempelvis för installation av anpassad sökväg (om din distribution inte har en uppdaterad version och du vill ha båda):

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

Denna artikel från Dr Dobbs visar i detalj GUI för felsökning på Linux OS. Jag rekommenderar Qt-Creator som heter GDB-felsökning baserat på Linux-miljö.Hur som helst, artikeln granskar endast felsökning av C ++ – kod, men det räcker för att visa upp GDB: s felsökningsfunktioner.

Jag rekommenderar UltraGDB , som är GDB GUI-fronten och lätt IDE baserat på Eclipse-teknik.

VisualStudio.Code ( VS.Code ) körs på Linux och har ett ”Native Debug” -tillägg som låter dig använda gdb. Det har mycket lyhörd användargränssnitt. Det är extremt lätt på resurser. Upplevelsen approximerar något Visual Studio på Windows för C ++ – utvecklare (det finns dock ingen monteringsvy). De viktigaste genvägarna för felsökning är desamma ur rutan (F5, Shift-F5, F10, F11).

Installationen är tvåklickad (en för att installera VS.Code, den andra för att installera tillägget), perfekt för någon som kommer från Windows Visual Studio och vill vara produktiv direkt.

Det finns ”s Voltron , vilket är ett utdragbart Python-felsökningsgränssnitt som stöder LLDB, GDB, VDB , och WinDbg / CDB (via PyKD) och körs på macOS, Linux och Windows. För de tre första stöder den x86, x86_64 och arm med jämnt arm64-stöd för lldb samtidigt som det lägger till jämnt powerpc-stöd för gdb.

Författaren skrev också ett binärt Ninja-plugin för att integrera Voltron – https://github.com/snare/binjatron – vilket möjliggör synkroniserade vyer.