edb-debugger: A Qt Debugger for x86 and AArch32 on Linux

What edb-debugger solves and who reaches for it

Most Linux debugging happens in a terminal. GDB is scriptable and everywhere, but it is not a windowed tool, and stepping through disassembly while watching registers, memory and a stack view side by side is awkward when every panel is a text command. edb-debugger exists to fill that gap. The README describes it as a cross platform AArch32/x86/x86-64 debugger inspired by Ollydbg, the Windows disassembler-debugger that reverse engineers grew up on. The target audience is therefore narrow and specific: people doing reverse engineering, malware triage or binary analysis on Linux who want a GUI rather than a command line. The topics on the repository, capstone, qt, reverse-engineering and security among them, confirm that framing. It is not a replacement for an IDE debugger when you already have source and symbols; it is aimed at the case where you are looking at a binary.

How edb is put together: Qt front end, Capstone disassembly, plugins

The architecture is visible in the repository layout. The top level holds include/, lib/, src/ and plugins/, and the build is driven by CMakeLists.txt. Qt supplies the interface, and the dependency table in the README requires Qt >= 5.15 or >= 6.8, which tells you the project tracks both major Qt lines. Capstone >= 3.0 is the disassembly engine, so instruction decoding is delegated rather than hand-written per architecture, which is what makes the AArch32, x86 and x86-64 claim plausible in one codebase. Graphviz >= 2.38.0 is optional and, given what Graphviz does, points at a control-flow graph view rather than anything on the debugging path. Plugins are a first-class part of the design: the README says make install places them in /usr/local/lib/edb, separate from the binaries in /usr/local/bin/. That split matters if you relocate the install, because the plugin directory is a fixed path in the documented flow. The README does not describe the plugin API or how a plugin is loaded, and defers that to the wiki.

Installing edb-debugger on Linux and running a first session

The README states that Linux is the only officially supported platform, and it points to wiki pages for Fedora, Ubuntu and Debian rather than listing package commands itself. Dependency installation is therefore distribution specific and not documented in the README, so check the wiki page for your distribution first. What the README does give is the clone and build sequence. Note the --recursive flag: the project uses submodules, and the README asks for it explicitly so that submodules are cloned and updated to the correct versions.

git clone --recursive https://github.com/eteran/edb-debugger.git

Once dependencies are in place, the README's out-of-tree build is four commands. This produces a binary you can run straight from the build directory without touching system paths.

mkdir build
cd build
cmake ..
make
./edb

For a system-wide install the only difference the README shows is the install prefix passed to CMake, followed by make install and then invoking edb from the path.

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local/ ..
make
make install
edb

After make install the README says plugins go to /usr/local/lib/edb and binaries to /usr/local/bin/. If you see edb start but plugins missing, that directory is the first thing to check. The README does not document a first debugging session, so how you load a target and set breakpoints is a wiki question, not a README one.

Where edb-debugger is the wrong tool

The clearest limitation is platform support, and the project states it plainly. Linux is the only officially supported platform; FreeBSD, OpenBSD, OSX and Windows ports are described as underway with varying degrees of functionality. Treat the non-Linux builds as unfinished work rather than as options. The second limitation is the kernel floor. The README notes that version 1.5.0 is the last release to support Linux kernels older than 3.0, that new development targets 3.0 and newer, and that the next major version will be 2.0.0. On an old kernel you are pinned to 1.5.0. Third, there is no packaged install path in the README: no apt, dnf or pacman line, just CMake and a wiki link, so anyone unwilling to install a C++17 compiler, Qt, Capstone and optionally Graphviz should look elsewhere. Finally, if your work is source-level debugging with symbols, a language debugger or an IDE is a better fit; edb's value is in the disassembly-and-registers view, not in stepping through your own functions.

edb-debugger against GDB and Immunity Debugger

The obvious alternative is GDB. The difference is the interface model, not the underlying capability: GDB is driven by commands and scripts, edb is driven by Qt windows, and the README's own framing (inspired by Ollydbg) tells you which tradition it follows. If you need to automate a session or run it over SSH without a display, GDB is the practical choice; if you want registers, memory and disassembly visible at once while you click through a binary, that is the gap edb occupies. Immunity Debugger is the other comparison people make, and the repository's own topic list includes ollydbg rather than immunity. Immunity Debugger is a Windows tool; edb's stated goal is the same style of workflow on AArch32, x86 and x86-64 across multiple operating systems, with Linux as the supported one. So the honest split is: Windows workflow, use Immunity Debugger or OllyDbg; Linux with a GUI, edb is the closer match; scripted or headless analysis, GDB.

Licence, releases and the cost of keeping edb current

edb is GPL-2.0, and the README points to the COPYING file for details. The practical consequence is the usual copyleft one: if you distribute a modified edb or link it into something you ship, the GPL-2.0 obligations travel with it. That is a consideration for anyone thinking of embedding the debugger in a commercial product, and it is a question for a lawyer rather than for this article. On maintenance, the last push to the repository was on 2026-09-05, so the codebase is being touched. Releases are much slower than commits: 1.5.0 landed on 2024-03-22, 1.4.0 on 2023-07-31 and 1.3.0 on 2020-12-14. That gap pattern means you should expect to build from master if you want current behaviour, and that the README's warning about a future 2.0.0 targeting newer kernels is a long-horizon statement rather than a near-term one. Upgrade cost is dominated by the Qt requirement: moving between Qt 5.15 and Qt 6.8 is a build-level change, and the dependency table lists them as alternatives rather than a single floor.

Editorial conclusion

Adopt edb if you want an OllyDbg-style GUI debugger on Linux and you are willing to build it from source with Qt, Capstone and a C++17 toolchain. Do not adopt it if you need a supported Windows or macOS workflow: the README says Linux is the only officially supported platform and calls the other ports variable in functionality. Before you commit, verify that your Qt version is at least 5.15 or 6.8, check the wiki page for your distribution, and run make install to see where the plugins land, since the README places them in /usr/local/lib/edb.

Frequently asked questions

Official sources

1. eteran/edb-debugger on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases