Seer: GUI-Frontend für GDB unter Linux

 (github.com/epasveer)
3 Punkte von GN⁺ 2024-11-16 | 1 Kommentare | Auf WhatsApp teilen
  • Seer ist ein Frontend, um GDB unter Linux per GUI zu bedienen, und wird aktiv mit dem Ziel entwickelt, eine einfache und ansprechend aussehende GUI für GDB bereitzustellen
  • Die Installation ist über den Paketmanager oder als Build aus dem Quellcode möglich; die Anforderungen sind Linux, C++17, GDB mit Unterstützung für den MI-Interpreter, CMake 3.5.0 oder neuer sowie Qt6
  • Qt5 lässt sich nicht mehr mit dem aktuellen Source Tree kompilieren; der 2.3-Source-Tree ist der letzte, der noch mit Qt5 kompilierbar ist, und v1.17 ist das letzte Qt5-Release
  • Seer bietet Source-Navigation, Anzeige von Variablen und Registern, Verwaltung von Breakpoints, Watchpoints, Catchpoints und Printpoints, Stack- und Thread-Ansichten sowie GDB Reverse Debugging in der GUI
  • Als zusätzliche Funktionen bietet es Assembly-Ansicht, Visualisierung von Speicher, Arrays, Structs und Bildern sowie eine I/O-Konsole für das ausgeführte Programm, sodass GDB-Debugging-Aufgaben visuell bearbeitet werden können

Projektüberblick

  • Seer ist ein GDB-GUI-Frontend für Linux
  • Ziel ist es, eine einfache und ansprechend aussehende GUI für GDB bereitzustellen
  • Das Projekt wird aktiv entwickelt; Bugs oder gewünschte Funktionen können per E-Mail oder über GitHub Issues gemeldet werden

Installation und Anforderungen

  • Seer kann über einen Paketmanager oder als Build aus dem Quellcode installiert werden
  • Anforderungen:
    • Linux
    • C++17
    • GDB mit Unterstützung für den mi-Interpreter
      • Prüfbefehl: gdb --interpreter=mi
    • CMake 3.5.0 oder neuer
    • Qt6
      • Beim Build aus dem Quellcode werden die zur Distribution passenden Qt6-Entwicklungspakete benötigt
      • Benötigte Qt6-Module sind Core, Gui, Widgets, PrintSupport, Charts und Svg
      • Qt6-Build-Anleitung: Building Seer - Qt6
  • Einschränkungen zu Qt5:

    • Seer lässt sich nicht mehr mit Qt5 kompilieren

      • Der 2.3-Source-Tree ist der letzte, der mit Qt5 kompilierbar ist
      • Qt5-Build-Anleitung: Building Seer - Qt5

Installationswege über Pakete

  • Pamac unter Manjaro:
    • pamac install seer
  • zypper unter openSUSE Tumbleweed:
    • zypper install seergdb
  • Flathub:
  • Flatpak-Beta-Version:
    • Seer release page
    • seer.flatpak herunterladen und installieren
    • Um GDB im GDB Launcher zu starten, ist flatpak-spawn --host erforderlich

Releases und Umstieg auf Qt

  • Neuigkeiten sind im Seer Wiki zu finden
  • v1.17 ist das letzte Qt5-Release
  • Das nächste Release ist v2.0 und basiert auf Qt6
  • Für eine gewisse Zeit ist die Kompilierung mit Qt5 noch möglich; wer jedoch den neuesten stabilen Qt5-Quellstand benötigt, sollte v1.17 verwenden

Ausführungsweise

  • Seer ist dafür gemacht, ein zu debuggendes Programm einfach von der Kommandozeile aus zu starten
  • Da GDB das Debugging von Programmen auf mehrere Arten unterstützt, bietet auch Seer verschiedene Startmethoden
  • Die Ausführungsweise ist im Wiki unter Starting Seer beschrieben

Aufbau der Haupt-GUI

  • Source/Function/Types/Variables/Libraries

    • Zeigt die Liste der im Programm verwendeten Source- und Header-Dateien an
    • Funktionen, Typen und statische Variablen können durchsucht werden
    • Per Doppelklick lässt sich eine Source-Datei öffnen
    • Zeigt die Liste der vom Programm referenzierten Shared Libraries an
    • Die Liste der Source- und Header-Dateien kann per Suche eingegrenzt werden

  • Variable/Register Info

    • Zeigt Variablen- und Registerwerte an
    • Logger zeichnet Variablenwerte auf
    • Tracker zeigt die Werte festgelegter Variablen jedes Mal an, wenn GDB einen Haltepunkt wie step, next oder finish erreicht
    • Registers zeigt die Werte aller CPU-Register an

  • Code Manager

    • Der große Bereich in der Mitte der Seer-GUI; Source-Dateien werden als Tabs angezeigt
    • Mit ^F kann innerhalb einer Datei nach Text gesucht werden
    • Variablennamen können per Doppelklick zum Logger hinzugefügt werden
      • CTRL-Doppelklick stellt der Variable ein * voran
      • SHIFT-Doppelklick stellt der Variable ein & voran
      • CTRL+SHIFT-Doppelklick stellt der Variable ein *& voran
    • Über das Rechtsklickmenü können Variablen zum Tracker oder Memory Visualizer hinzugefügt werden
    • In einer bestimmten Zeile können Breakpoints oder Printpoints erstellt werden
    • Die Ausführung kann bis zu einer bestimmten Zeile fortgesetzt werden
    • Tabs können per Doppelklick abgetrennt werden

Debugging-Steuerung und Anzeige des Ausführungszustands

  • Der untere Bereich behandelt Breakpoints, Watchpoints, Catchpoints, Printpoints, manuelle GDB-Befehle und Logs
  • Im Tab für manuelle Befehle können GDB- oder GDB/MI-Befehle direkt eingegeben werden
    • Eingegebene Befehle werden für die nächste Nutzung von Seer gespeichert
  • Der Breakpoint Manager erstellt und verwaltet Breakpoints
  • Der Watchpoint Manager überwacht Variablenzugriffe
    • Lesen, Schreiben sowie Lesen und Schreiben können überwacht werden
  • Der Catchpoint Manager hält die Ausführung bei C++-Aufrufen von throw, rethrow und catch an
  • Der Printpoint Manager kann wie GDBs dprintf an bestimmten Stellen Variablen ausgeben
  • GDB output protokolliert die Ausgabe des GDB-Programms selbst
  • Seer output protokolliert diagnostische Ausgaben des Seer-Programms
  • Stack-Frame-Informationen:
    • Durch Doppelklick auf die Frameliste kann der aktuelle Funktions-Scope gewechselt werden
    • Zeigt die Funktionsargumente jedes Frames an
    • Zeigt die Werte lokaler Variablen der aktuellen Funktion an
  • Thread-Informationen:
    • Zeigt die Liste aller Thread-IDs an
    • Durch Doppelklick auf eine Thread-ID kann der aktuelle Thread-Scope gewechselt werden
    • Listet die Stack Frames jedes Threads auf
  • Unterstützt den Reverse-Debugging-Modus von GDB
    • Die Befehlsaufzeichnung kann ein- oder ausgeschaltet werden
    • Die Wiedergaberichtung kann auf forward oder reverse gesetzt werden

Konsole und Assembly-Ansicht

  • Seer Console zeigt sämtliche Textausgaben der ausführbaren Datei an
  • Texteingaben für die ausführbare Datei können ebenfalls in der Konsole eingegeben werden
  • Assembly View fügt neben dem Source-Code-Tab einen Tab hinzu, der die aktuell ausgeführte Assembly anzeigt
    • Aktivierung über View->Assembly View
    • Auch im Assembly-Tab können Breakpoints gesetzt werden
    • Die aktuelle Instruktion wird hervorgehoben
    • Ein Doppelklick auf Einträge im Breakpoints-Tab oder Stack-frames-Tab zeigt die Assembly an der entsprechenden Adresse
    • Unterstützt die Tastenkürzel Nexti und Stepi; die Standardwerte sind in der Regel Ctrl+F5 und CTRL+F6
    • Mit ^F im Assembly-Tab wird eine Suchleiste angezeigt
    • Diese Assembly-Funktion ist neu; Änderungs- und Funktionsvorschläge werden entgegengenommen

Visualisierungswerkzeuge

  • Memory Visualizer

    • Ermöglicht das Anzeigen roher Speicherinhalte
    • Kann in Speicher- und Disassembly-Form angezeigt werden

  • Array Visualizer

    • Visualisiert Array-Inhalte
    • Bietet die Darstellungsarten Normal, Spline und Scatter
    • Zwei Arrays können als X-Y-Plot verwendet werden
    • Das Beispiel-Array points bildet eine X-Y-Kontur

  • Struct Visualizer

    • Zeigt Inhalte von C/C++-Structs oder C++-Klassen an
    • Das Beispiel zeigt den Inhalt von *this der aktuellen C++-Klasse
    • Struct-Member mit Basistypen können bearbeitet werden
    • Es gibt auch einen Basic Struct Visualizer, der leichtergewichtig ist, aber keinen Pointern folgen und nicht bearbeiten kann

  • Image Visualizer

    • Kann verwendet werden, um rohe Speicherinhalte zu betrachten, die ein Bild darstellen

Support und Kontakt

  • Bugs oder Feature Requests können an epasveer@att.net gesendet oder als GitHub Issue eingetragen werden
  • Issue eintragen: GitHub issues

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-16
Meinungen auf Hacker News

  • Ich habe es unter Linux zusammen mit Godot gebaut und ein wenig ausprobiert. Insgesamt ist es in Ordnung, aber die UI wirkt mit Widgets überladen und etwas unausgereift.
    Das Ändern der Editor-Schriftart funktionierte nicht, und wenn man mit der Maus über eine Variable fährt, um den Wert zu sehen, passiert entweder nichts, oder der Cursor ändert sich nur ganz kurz, woraufhin GDB einen Fehler ausgibt, dass versucht wurde, einen Ausdruck mit einem Typ/Keyword zu verwenden.
    Ein Doppelklick auf eine Variable fügt den aktuellen Wert und einen Zeitstempel in einem Panel hinzu; die UI hat also grundsätzlich eine Funktion zum Lesen von Werten/Ausdrücken, aber die Tooltip-Implementierung scheint kaputt zu sein.
    Mit etwas Feinschliff könnte es nützlich sein, aber das Frontend, das ich bisher am wenigsten nicht mochte, war Gede. Die UI ist schlicht und intuitiv, und auch wenn es nicht viele Funktionen hat, funktionieren die sichtbaren Funktionen meist fehlerfrei: https://gede.dexar.se/

    • Ich bin der Autor von Seergdb. Es wäre gut, wenn du genauer erklären könntest, was du damit meinst, dass die Editor-Schriftart nicht gesetzt werden kann; in meinen Tests scheint es zu funktionieren.
      Um Einstellungen dauerhaft zu speichern, muss man „Save Configuration...“ verwenden. Die Mouse-over-Anzeige von Variablenwerten werde ich ebenfalls testen; Bugs oder Feature Requests am besten als GitHub-Issue hinterlassen.
    • Wenn ich Bugs in meinem eigenen Code suche, möchte ich mich nicht auch noch mit Bugs im Debugging-Tool herumschlagen müssen; ich merke mir Gede für das nächste Mal vor, wenn ich debuggen muss.

  • GDB hat überraschenderweise auch eine leicht zu bedienende eingebaute Text User Interface (TUI). Sie unterstützt sogar Mausinteraktion: https://sourceware.org/gdb/current/onlinedocs/gdb.html/TUI.h...

    • Persönlich bevorzuge ich die Kommandozeile gegenüber der TUI, aber man kann so etwas in .gdbinit eintragen:
      tui new-layout default regs 1 {-horizontal src 1 asm 1} 2 status 0 cmd 1
      tui layout default
      tui enable
    • Die Kombination Neovim + nvim-dap + nvim-dap-ui + gdb war deutlich besser als das.
    • Leider funktioniert es nur, wenn GDB mit TUI-Unterstützung gebaut wurde.

  • Nachdem ich mehrere GDB-Frontends ausprobiert habe, halte ich die TUI für die beste Option. Wenn das Programm Ausgaben schreibt und dadurch die Oberfläche durcheinanderbringt, muss man zum Neuzeichnen nur Ctrl + L kennen.
    In $XDG_CONFIG_HOME/gdb/gdbinit steht bei mir nur Folgendes:
    layout src
    set confirm off

    • Für einen farbigen Prompt verwende ich gern Folgendes:
      set prompt \001\033[01;36m\002(gdb)\001\033[0m\002
      Die History speichere ich so:
      set history save on
      set history size 500000
      set history filename ~/.cache/gdb/history
    • Ich habe gdb-dashboard viel genutzt und kann es empfehlen. Es ist der TUI ähnlich, aber man kann viel genauer auswählen, welche Informationen angezeigt werden, und dank der Farben ist die Ausgabe deutlich leichter lesbar.
      Man kann das Dashboard auch in einem anderen Terminal oder auf mehrere Terminals verteilt anzeigen lassen, wodurch bessere Fenster-Layouts möglich sind. Früher hatte ich ein Script, das mit tmux automatisch ein Terminal-Layout erzeugte und sich mit GDB verband; das war zwar ziemlich aufwendig, ergab aber ein recht gutes Layout.
    • Ctrl + L muss man bei TUI-artigen Oberflächen unbedingt kennen, auch wenn der Vim-Bildschirm kaputt aussieht. Seit ich das weiß, haben sich zahlreiche rätselhafte „Abstürze“ aufgeklärt.
    • gef unterstützt tmux, sodass Programmausgaben in ein anderes tmux-Panel gehen.
    • Das gud-gdb-Frontend in Emacs ist ziemlich praktisch und einfach zu benutzen.

  • Auch wenn man von Windows aus mit Linux verbunden ist oder WSL nutzt, kann man Linux-Prozesse mit WinDBG/VisualStudio remote debuggen.

    • Reicht es nicht, wenn auf der Remote-Seite gdbserver läuft?

  • Das hier ist eine Qt-UI für GDB.
    Soweit ich weiß, gibt es mit gdbgui auch eine webbasierte UI für GDB: https://www.gdbgui.com/
    Es ist immer gut, wenn sich bei Debugging-Tools mehr bewegt.

    • Mir gefällt, dass GDB in Qt Creator ohne komplizierte Konfiguration funktioniert. Man setzt ein paar Breakpoints und drückt einfach auf Ausführen, den Rest erledigt die IDE.
    • Um der Liste der GDB-GUIs noch eine hinzuzufügen: Ich habe auch eine gebaut: https://github.com/dzaima/grr
      Es fehlen noch einige Funktionen, die für manche Anwendungsfälle unverzichtbar sein könnten. Das liegt daran, dass meine Nutzung vor allem Debugging auf Assembly-Ebene ist und ich daher nicht viele ausgefallene Funktionen brauchte.
    • Es gibt auch DDD. Das ist ein Motif-Frontend.
    • VS Code hat ebenfalls ein ordentliches GDB-Frontend und ist besonders gut beim Debugging von Embedded-Mikrocontrollern.
    • Wo wir gerade bei webbasierten Debuggern sind: Ich habe kürzlich ein ähnliches Projekt gebaut, das sich auf das Debugging von x86-64-Assembly konzentriert: https://github.com/robalb/x86-64-playground

  • Vor zwei Jahren gab es dazu auch schon eine Diskussion mittlerer Größe: https://news.ycombinator.com/item?id=33044885

  • Für Emacs-Nutzer ist GUD eine ziemlich gute GDB-Integration

    • Seit dem Aufkommen von LSP fühlt sich Emacs besser an als alles andere. Es gibt keinen Grund zu wechseln. Besonders, seit es durch native Kompilierung schneller geworden ist
      Es gibt keinen Grund, ständig den neuen Editor des Monats auszuprobieren, nur weil er ein paar spielzeugartige Features hinzugefügt hat. Mit einem Plugin in Emacs bekomme ich dieselben Funktionen und der Rest bleibt genau so, wie ich es mag
      Ich bin in der Atom-Zeit richtig ins Programmieren eingestiegen, und ich fand es ziemlich schade, dass Atom verschwunden ist und daraus VS Code wurde. VS Code ist gut, folgt aber nicht derselben Philosophie wie Atom
      Seit ich vor etwa vier Jahren Emacs gelernt habe, hat mich kein neues Tool davon überzeugt: „Das ist alte Technik, du solltest wechseln.“ Eine etwas zusammenhanglose Tirade, aber ich bin wirklich dankbar, dass Emacs weiterlebt
    • Ich bevorzuge M-x gdb, Emacs’ GDB Graphical Interface, gegenüber der einfachen Integration über GUD, M-x gud-gdb
      Kürzlich musste ich zu GUD wechseln, um lldb auszuführen, und mir fehlten die eigenen Fenster für Breakpoints, Threads, den aktuellen Stack usw.
      Das Gute an GUD ist, dass die Oberfläche über verschiedene Debugger hinweg konsistent ist. Wenn man also von Python-Debugging mit pdb zu C++-Debugging mit lldb wechselt, muss man die Tastenkürzel nicht neu lernen
      https://www.gnu.org/software/emacs/manual/html_node/emacs/GD...
      https://www.gnu.org/software/emacs/manual/html_node/emacs/St...
    • dape (https://github.com/svaante/dape#) ist eine gute Option für Sprachen, für die es Debugger gibt, die das Debug Adapter Protocol implementieren
      Zusammen mit debugpy nutze ich M-x pdb nicht mehr, und die UI ist M-x gdb sehr ähnlich
    • lsp-mode + dap-mode funktioniert ebenfalls gut, allerdings muss man die Datei launch.json in gewissem Umfang selbst anfassen

  • Gefällt mir. Es erinnert mich an DDD, das mir beim ersten Anblick wie Magie vorkam. Überraschend, dass DDD noch gepflegt wird
    https://en.wikipedia.org/wiki/Data_Display_Debugger
    https://www.gnu.org/software/ddd/

    • Ich habe DDD vor 20 Jahren an der Uni gelernt, und schon damals wirkte es klobig. Heute sehe ich es deutlich wohlwollender, aber Motif ist immer noch ein Dorn im Auge
      Nach Gesprächen über Jahre hinweg war DDD paradoxerweise ein hervorragendes Anti-Marketing-Tool und hat Entwickler in die eingebauten Debugger-UIs ihrer bevorzugten IDEs getrieben. DDD selbst ist zwar sehr mächtig, aber auch „Nützlichkeit ist wichtiger als Ästhetik“ hat Grenzen
    • Natürlich wird DDD gepflegt. Über die Funktionen habe ich hier geschrieben: https://begriffs.com/posts/2022-07-17-debugging-gdb-ddd.html
      Nachdem ich den Artikel geschrieben hatte, haben die Maintainer die von mir angesprochenen Probleme behoben, sodass inzwischen viele Workarounds nicht mehr nötig sind. 3.4.0 und 3.4.1 sind ziemlich große Releases
    • Mir gefällt, dass DDD verschiedene grafische Visualisierungen eingebaut hat. Besonders die Visualisierung von Datenstrukturen fand ich immer großartig
      Früher gab es ein Projekt, das es auf GTK3 portieren wollte, aber das scheint verschwunden zu sein. Trotzdem bin ich froh, dass das Mainline-Projekt weiterläuft
    • Das erinnert mich an Insight, mein liebstes GDB-Frontend, das zu Cygwin-Zeiten unter Windows gut funktionierte. Leider wird es definitiv nicht mehr gepflegt: https://sourceware.org/insight/screenshots.php
      Es sieht aber so aus, als hätte es jemand auf GitHub umgezogen, wiederbelebt und ein wenig daran gearbeitet: https://github.com/antony-jr/insight
    • DDD ist großartig. Ich benutze es immer noch, aber ich bin auch ein Fossil
      Ich habe nach etwas gesucht, das dem dbxtool ähnelt, das ich früher auf Sun-Microsystems-Maschinen benutzt habe, und bin dabei auf DDD gestoßen. Heutzutage haben die Leute mit Dingen wie Source-Level-Debugging ziemlich viel Luxus

  • Das GNU-Projekt und RMS scheinen oft wie ein Meme verspottet zu werden, aber GDB ist ein mächtiges Werkzeug. Ich habe nur ein wenig selbst damit herumprobiert, aber es scheint über Jahre hinweg einen enormen Einfluss auf die Arbeit von Entwicklern gehabt zu haben

    • Rein aus Neugier: Wofür wird GNU verspottet?

  • Als ich vor über 10 Jahren unter Linux C++ geschrieben habe, habe ich Qt Creator mit eingebautem Debugger genutzt. Es ist ein GDB-Frontend, funktionierte sehr gut, und für C++ und Qt sah ich keinen Grund, etwas anderes zu verwenden