# Seer: a Qt frontend to gdb for Linux debugging

> Seer wraps gdb in a Qt GUI for Linux, exposing breakpoints, watchpoints, catchpoints, printpoints and register views over gdb's MI interpreter. It is GPL-3.0, C++17, and requires Qt6 to build from source.

**epasveer/seer** — Seer - a gui frontend to gdb

- Repository: https://github.com/epasveer/seer
- Stars: 3,443 · Forks: 117
- Language: C++
- License: GPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/epasveer-seer

## What Seer solves for Linux C++ debugging

gdb is a terminal program. Setting a breakpoint, stepping, then inspecting a struct means typing commands and reading text output, and keeping track of several variables across a session means repeating print statements. Seer puts a Qt window in front of gdb so the same operations happen through lists, tabs and dialogs. The README describes it as "a simple, yet pleasing gui to gdb", and the author states the project is actively worked on.

The audience is narrow and specific: developers debugging C or C++ on Linux who already know what a breakpoint is and want gdb's features without the command line. The README lists the requirements as Linux, C++17, gdb with the mi interpreter, CMake 3.5.0 or newer, and Qt6. There is no Windows or macOS build described anywhere in the README, and the first line calls it a frontend "for Linux".

## How Seer drives gdb through the MI interpreter

Seer is a GUI client, not a debugger. gdb does the work; Seer sends commands and renders the results. The README states the requirement plainly: gdb with the "mi" interpreter, checkable by running gdb --interpreter=mi. MI is gdb's machine interface, a line-oriented protocol designed for frontends, and it is what lets Seer populate structured views instead of scraping human-readable text.

The interface is organized around a main view. A source, function, types and variables panel lists the files used by the program and lets you search functions, types and static variables. Below that, a variable and register panel offers a Logger for individual values, a Tracker that re-prints a list of variables every time gdb stops at a step, next or finish, and a Registers view for CPU registers. The Code Manager in the middle opens source files, supports search with Ctrl+F, and turns right-click actions into breakpoints, printpoints or run-to-line commands. A lower area holds managers for breakpoints, watchpoints, catchpoints and printpoints, plus manual gdb or gdbmi command entry and two logs, one for gdb output and one for Seer's own diagnostics. Stack frames, thread lists and a console for the debugged program's text input and output round out the layout.

The design choice worth noting is that Seer does not hide gdb. Manual gdb and gdbmi commands can be typed into the lower panel, and the README says those commands are remembered for the next Seer use. That makes Seer a layer over gdb rather than a replacement, which is a reasonable trade: you keep the full command set, but you also inherit gdb's setup requirements, including the MI interpreter.

## Installing Seer from a package manager or from source

The README gives two paths: a package manager or a source build. On Manjaro, Pamac carries it:

```bash
$ pamac install seer
```

On openSUSE Tumbleweed the package is named seergdb:

```bash
$ zypper install seergdb
```

Flathub hosts the stable build, and the README gives the command:

```bash
$ flatpak install flathub io.github.epasveer.seer
```

There are also beta channels. The Snap development release installs from a downloaded snap file with the dangerous flag, and the Flatpak beta installs from a bundled file:

```bash
$ flatpak install -y --bundle --user seer.flatpak
```

One caveat is attached to the Flatpak build: the README marks it important that flatpak-spawn --host is needed in the GDB Launcher to run gdb, and links to issue 377 for the details. If you install through Flatpak and gdb does not start, that is the first thing to check.

Building from source is documented in the project wiki rather than the README. The README points to the Qt6 build instructions at the Seer wiki page Building-Seer---Qt6 and calls that path recommended. It also states that Seer no longer compiles with Qt5, and that the 2.3 source tree is the last one that does. Source builds need the Qt6 devel packages for Core, Gui, Widgets, PrintSupport, Charts and Svg, plus CMake 3.5.0 or newer and a C++17 compiler.

## A first session: breakpoints, trackers and printpoints

Seer is started from the command line, and the README says it is meant to start the program to debug that way, with several methods mirroring gdb's own. The wiki page Starting-Seer documents all of them; the README does not reproduce the full list, so treat the wiki as the source for launch forms.

Once a program is loaded, the working pattern is: open a source file in the Code Manager, right-click a line to set a breakpoint, run, then inspect. Two features distinguish the workflow from plain gdb. The Tracker builds a list of variables and re-prints their values every time execution stops at a step, next or finish, which removes the need to re-enter print commands after each step. Variables are added to it by selecting a name and choosing Add variable to Tracker from the right-click menu.

The Logger is the other one. Double-clicking a variable name in the Code Manager adds it to the Logger, and the README documents modifier keys that change what is logged: Ctrl prepends the name with *, Shift prepends it with &, and Ctrl+Shift prepends it with *&. Those prefixes correspond to gdb's pointer and address forms, so the same gesture covers a value, a pointer target or an address without retyping an expression.

Printpoints are the third piece. The README describes a printpoint as like a breakpoint but allowing you to print variables at that point, and ties it to gdb's dprintf call. That means you can instrument a line without stopping execution there. Watchpoints, which monitor reads, writes or both on a variable, and catchpoints, which stop on C++ throw, rethrow or catch, are managed from the same lower panel. For a first real session, set one breakpoint, add two variables to the Tracker, and step; the value panel should update at each stop.

## Where Seer stops being the right tool

The constraints are mostly environmental, and they are firm. Seer is Linux only. Nothing in the README describes a Windows or macOS build, so if your team debugs on those platforms, Seer is not a candidate regardless of how the GUI looks.

Qt6 is the second constraint. The README states in bold that Seer no longer compiles with Qt5 and that the 2.3 source tree is the last one that does. If you are pinned to a distribution that ships Qt5 only, you are choosing between an old Seer tree and no Seer, and the README does not describe a migration path beyond that sentence. This is a real cost for long-lived build images.

The third is gdb itself. Because Seer is a frontend, it inherits gdb's behavior and its configuration. If your gdb build lacks the mi interpreter, Seer has nothing to talk to; the README's own check is gdb --interpreter=mi. The Flatpak packaging adds another layer, since the README requires flatpak-spawn --host in the GDB Launcher for gdb to run at all, a sandbox interaction rather than a Seer bug.

Finally, consider what you give up. A terminal gdb session is scriptable and reproducible; you can put commands in a file and replay them. Seer's manual command panel remembers what you typed, but the README does not describe a script or session-file mechanism for replaying a GUI session. If your debugging is driven by scripts or CI, plain gdb remains the better fit.

## Seer against gdbgui and plain gdb

The obvious comparison is gdbgui, the browser-based gdb frontend that appears in the related searches for this project. The difference in approach is architectural. gdbgui runs as a server and you attach a browser to it, which makes remote debugging over a network natural and lets you use any machine with a browser as the client. Seer is a native Qt desktop application, so the GUI and the debugger session live on the same Linux machine, and there is no browser or server component to configure. That is simpler to start and harder to use remotely.

The second comparison is plain gdb with no frontend at all. Seer does not add debugging capability; it changes how you reach the capability that is already there. Everything Seer shows, gdb can print. What Seer adds is persistence of state across stops through the Tracker, and a visual layout for breakpoints, watchpoints, catchpoints and printpoints. If you are comfortable in the gdb prompt and your sessions are short, a frontend is overhead. If you spend hours stepping through code and re-printing the same six variables, the Tracker and the Logger are the features that justify the install.

Seer also supports gdb's reverse debugging mode, with controls to turn instruction recording on or off and to set playback direction forward or reverse. That is a gdb feature reached through the GUI, not a Seer invention, and it is worth knowing it exists before you assume a frontend can only move forward.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-13. Releases in the recent list include v2.7 on 2026-04-06, a Snap development release on 2026-08-30 and a Flatpak development release on 2025-12-11. The README itself says the project is actively worked on, and the issue tracker is where the author asks for bug reports and feature requests.

Upgrade cost is concentrated in the Qt transition. The README's news section states that v1.17 will be the last Qt5 release and that the next release will be v2.0, Qt6 based, and that Seer no longer compiles with Qt5. Anyone building from source therefore needs Qt6 devel packages for Core, Gui, Widgets, PrintSupport, Charts and Svg. Package manager users absorb that cost through their distribution's packaging, which is the lower-effort route.

The licence is GPL-3.0, as stated in the repository's LICENSE file and the project metadata. Seer links against Qt and drives gdb, both of which carry their own licences, and the README does not discuss licence compatibility or distribution obligations. If you plan to redistribute Seer, or ship it inside a product, that is a question for your own legal review rather than something the README answers.

## Conclusion

Adopt Seer if you debug C or C++ on Linux and want gdb's MI features behind a Qt interface, and you can install it from Pamac, zypper, Flathub or the Snap bundle. Do not adopt it if you need macOS or Windows support, if your gdb lacks the mi interpreter, or if you are still on Qt5, since the README states Seer no longer compiles with Qt5 and points to the 2.3 source tree as the last one that does. Before committing, run gdb --interpreter=mi to confirm your gdb supports MI, and if you use the Flatpak build, check that flatpak-spawn --host works in the GDB Launcher as the README requires.

## FAQ

### What does GDB stand for?

GDB is the GNU Debugger, the program Seer drives. The README requires gdb with the mi interpreter, which you can check by running gdb --interpreter=mi.

### Is GDB difficult to learn?

The README does not discuss the learning curve. It positions Seer against the terminal workflow by describing itself as a simple GUI to gdb, and it keeps manual gdb and gdbmi command entry available in the lower panel for users who already know the commands.

### What is GDB used for?

GDB is the debugger Seer fronts. Through Seer it is used for breakpoints, watchpoints, catchpoints, printpoints, stack frame and thread inspection, register views and reverse debugging on Linux.

## Sources

- [epasveer/seer on GitHub](https://github.com/epasveer/seer)
- [Issues](https://github.com/epasveer/seer/issues)
- [License: GPL-3.0](https://github.com/epasveer/seer/blob/main/LICENSE)
- [README](https://github.com/epasveer/seer/blob/main/README.md)
- [Releases](https://github.com/epasveer/seer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/epasveer-seer