CGDB puts your source above a split GDB session and borrows vim's keys

A wrapper around GDB, not a replacement for it

CGDB is described as a very lightweight console frontend to the GNU debugger. The mechanism is the important part and it is simple: GDB still runs, still speaks its own command language, and CGDB draws a split screen with the GDB session on the bottom and your program's source code on the top.

Because GDB remains the engine, everything you already know about GDB still works. Breakpoints, watchpoints, the command language, remote targets, all of it is untouched. What CGDB adds is the pane, the source display, and a keymap. That boundary is why the project can stay small enough to describe in a paragraph and why its dependency list is about build tooling rather than about debugging libraries.

The interface is modelled after vim, and the README says vim users should feel right at home. That is the whole positioning statement. There is no plugin system described, no scripting language, and no configuration format mentioned in the README beyond the generated header file `cgdb_custom_config.h.in`, which is the autotools template for compile-time options rather than a user-facing settings file.

If you have ever used a curses debugger that tries to abstract the prompt away, the difference here is that it does not. The GDB prompt stays a GDB prompt.

Build dependencies are autotools plus a lexer and parser generator

The dependency list is explicit, and it tells you what you are signing up for. You need sh, autoconf, automake, aclocal, autoheader, libtool, flex, bison, and a gcc/g++ with C11 and C++11 support. The flex and bison entries are the ones that matter practically: CGDB parses GDB's own output, so the build generates that parser rather than shipping it pre-generated.

Generate the configure script first, from the top of the source tree:

./autogen.sh

Then the build. The README notes that you can run ./configure from inside the source tree, but recommends running it from a separate build directory instead:

mkdir ../build
cd ../build
../cgdb/configure --prefix=$PWD/../prefix
make -srj4
make install

The `-srj4` is the author's habit rather than a requirement, and the prefix is pointed at a sibling `prefix` directory so a local build does not overwrite a system installation.

Official source releases are also hosted separately at https://cgdb.me/files/, with screenshots, downloads and documentation on the project home page at https://cgdb.github.io.

C11 and C++11 may need explicit flags on your compiler

CGDB is a C11 and C++11 project, described in the README as being like GDB in that respect. The consequence is stated just as plainly: since the standard is relatively new, your gcc or g++ may support it out of the box, or may require you to pass `-std=c11` and `-std=c++11` yourself.

The README then shows the flag set the author actually uses, which is worth reading as a template for a debug build rather than copying blindly:

YFLAGS="-Wno-deprecated" CFLAGS="-std=c11 -g -O0 -Wall -Wextra -Wshadow -pedantic -Wno-unused-parameter" ../cgdb/configure --prefix=$PWD/../prefix

Two details there are easy to miss. The `-g -O0` pair is what you want while hacking on a debugger frontend, and `-Wshadow` plus `-pedantic` is a stricter regime than most packaged builds use.

If the libtool link lines are noisy during the build, there is a documented way to quiet them:

LIBTOOLFLAGS=--silent

That is set as an environment variable rather than passed to configure, which is the kind of detail the README is unusually willing to document.

Repository layout tells you where the pieces live

The top level is a conventional autotools project with more than the minimum in it. `configure.ac` and `Makefile.am` drive the build, `autogen.sh` bootstraps it, and `cgdb_custom_config.h.in` is the generated compile-time configuration header.

The implementation directory is `cgdb/`, the shared code lives in `lib/`, and documentation is in `doc/`. Two directories show the project's process rather than its product: `testsuite/` holds tests, and `packages/` holds packaging material for the platforms it ships to.

There is also a set of plain text files that reveal how the project is run. `AUTHORS`, `CONTRIBUTING.md`, `COPYING`, `ChangeLog`, `FAQ`, `INSTALL`, `NEWS`, `release-todo.txt` and `roadmap.txt` sit at the root. `NEWS` and `ChangeLog` are the ones to read when upgrading, and `roadmap.txt` and `release-todo.txt` are where the maintainer records intent rather than history.

Release handling is scripted too: `autorelease.sh` sits next to `autogen.sh`, and `config/` holds the autotools auxiliary files. The `.indent.pro` file is an indent configuration, which suggests the source is still formatted with GNU indent at least in part.

Three releases in one day, and a version scheme to watch

The release list shows v0.7.0, v0.7.1 and v0.8.0 all published on 2026-10-05, within about half an hour of each other. That pattern is consistent with tagging a batch of accumulated work after the fact rather than cutting a release per change.

The practical effect for a user is that the version number tells you very little about what changed. Read the `NEWS` and `ChangeLog` files in the tree for that, or diff the tags yourself. If you are pinning CGDB in a build script, pin a commit or a specific tag deliberately rather than assuming 0.8.0 is the newest thing to land.

The last push was on 2026-10-06, one day after those tags, and the repository is not archived. Maintenance is therefore current, though the project is still on a 0.x version, which in this ecosystem usually means the interface can still change.

Licensing is GPL-2.0, with `COPYING` at the root. For most people CGDB is a developer tool installed on their own machine, where that is uneventful. It matters if you intend to bundle CGDB into a product or redistribute it, which is a question for your own legal review.

When CGDB is the wrong choice

If your debugging already happens inside an editor, CGDB adds a terminal you have to leave. Modern IDEs show source, stack, locals and breakpoints in one window without a second pane, and for a project where you spend most of your time editing rather than stepping, that integration is the more direct route.

If you are comfortable reading GDB's own commands, the source pane is a convenience rather than a capability. GDB's `list`, `info line` and TUI already put source on screen. CGDB's contribution is the continuous split and the vim keys, and if you do not use vim, the second half is worth nothing to you.

The build is also not free of friction. flex, bison and libtool are required, and if you are on a system where those are unavailable or where you build inside a restricted sandbox, CGDB cannot be built from the source tree at all. There is no prebuilt binary referenced in the README beyond the release tarballs.

And a split pane only shows one file at a time in a small terminal window. If your debugging sessions involve following a call chain across many translation units, a full editor integration with a proper call tree is the better instrument, and CGDB does not attempt to be one.

Editorial conclusion

GDB users who want source context without leaving a terminal should build CGDB from source, since the value it adds is a split pane and a vim keymap rather than any new debugging capability. If you are happy with plain GDB, TUI or an editor integration, CGDB adds a build dependency on flex, bison and libtool for no functional gain. Before adopting, generate configure with ./autogen.sh and confirm your gcc supports C11 and C++11, since the README notes some compilers need the -std=c11 and -std=c++11 flags passed explicitly to configure.

Frequently asked questions

Official sources

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