Seer: A GUI front end to GDB for Linux

Original Article ↗ Hacker News Discussion ↗

Seer and Other GDB GUIs

  • Seer is a Qt-based GUI frontend to GDB on Linux.
  • Users note it’s featureful but somewhat “widget-heavy” and still rough in places: issues with editor font changes and hover-to-see-variable-value behaving inconsistently.
  • The author is responsive, asks for bug reports, and has acknowledged and filed issues based on feedback.
  • Some compare Seer to kdbg and Gede; Gede is praised for a simpler, more stable UI, even if less feature-rich.

Legacy GUI Debuggers (DDD, Insight, etc.)

  • DDD evokes nostalgia: powerful but historically clunky and ugly (Motif), yet still maintained and improved (newer releases, TTF, better Motif).
  • Its graphical struct/pointer visualization is highlighted as a unique, highly educational feature for understanding pointers and data structures.
  • Some recall DDD as crash-prone or an “inverse marketing tool” that pushed people toward IDE-integrated debuggers.
  • Insight is remembered fondly as a former favorite GDB frontend, now mostly unmaintained but partially revived on GitHub.

Debugger Performance and Configuration

  • Some report GDB on Linux being much slower than Visual Studio’s debugger on Windows, especially on large, heavily templated C++/Qt codebases with many dependencies.
  • Others with large codebases (millions of LOC) say stepping is instant, suggesting configuration issues (e.g., reverse debugging, debuginfod, symbol indexing).
  • Suggested mitigations include DWARF5 with accelerator tables, certain GDB settings (e.g., deprecated index sections, styles off), and disabling heavy pretty-printers.

Frontends in IDEs and Editors

  • Many prefer integrated debuggers: Qt Creator, VS Code, Eclipse CDT, Emacs (GUD / graphical GDB), Neovim (DAP), CLion, JetBrains IDEs, and web-based tools like gdbgui.
  • GDB’s TUI mode is praised as simple and powerful, though it depends on being built with TUI support; some distros historically did not.
  • Emacs and Neovim users highlight modern DAP-based integrations and custom layouts as strong alternatives to standalone GUIs.

Debugger vs Printf/Logging

  • Large subthread debates step-debugging vs printf/log/logging.
  • Pro-debugger arguments: faster exploration, visibility into full state, conditional and logging breakpoints, good for complex or multithreaded bugs, and “time-travel” record/replay tools (rr, Undo, WinTTD).
  • Pro-logging arguments: works everywhere (HPC, containers, production), easy to persist and diff, better for long-running or distributed systems, and often sufficient when combined with tests.
  • Consensus: both techniques are valuable; many bugs benefit from combining logs, unit tests, and advanced debugger features.