Have you compared debuggers lately? Until recently, I'd been programming using only one debugger  the one supplied by my compiler vendor. Suddenly, with a new job programming on Linux, I find the range of choices in debuggers is dizzying. Wikipedia lists 18 GUI front ends for GDB alone. This article is the result of my effort to choose a debugger with a good GUI front end for my first UNIX/Linux job in several years.

Scope

There are many tools that provide functionality related to debugging. Examples include memory-leak detectors, memory-corruption detectors, profilers, and gdb enhancers such as undoDB. And with multithreaded programming going mainstream, there are single-purpose tools to help diagnose deadlock and race conditions. Those tools, while valuable, are not part of this review  I'm solely focusing on debuggers, and specifically, the user-friendliness of the interfaces. The focus on the user experience is intentional and specific: I find that the vast majority of the time in the debugger involves two principal activities  stepping through code and examining variables. In the next section, I show a screen capture of each product and I comment on how well it provides these functions in addition to how well it enables me to move and dock tabs so that I can maximize my screen space.

In subsequent sections, I rate the products on other common features, such as setting breakpoints, customizing variable display, and so on. I also explain my thinking on what makes good implementations of some of these features now that I've seen them implemented across these 13 products, some standalone and some embedded in IDEs.

Products

Affinic Technology's Affinic 0.5.3 (recently updated to version 1.0) is a commercial GUI wrapper for GDB. It can be downloaded and tried out for free. A commercial license costs $49. Versions for Linux and Windows (via Cygwin) are available. Affinic uses single-button hotkeys and buttons for stepping through the target program. Its variable display is usable but minimal. Its tabbed docking windows would be good if they remembered their position from one debugging session to the next. The "variable display tooltip" is bare bones: Hovering the cursor over a variable displays as much of its value as will fit in the single status line at the bottom of the main window.



Figure 1: The Affinic debugger.

Code::Blocks 12.11 is a free, open-source product that uses a plugin model to add various capabilities, which I'll touch on later. It offers tabbed docking windows, but they won't dock together into user-selected groups. Its variable display understands STL vectors, but not STL strings. Its tooltips show variable values for only the simplest data types, and its program console window isn't part of its docking system.



Figure 2: Code::Blocks.

Codelite 5.1 is an open-source C++ IDE that runs on Windows, Linux, Mac OS X, and FreeBSD among other platforms. It has tabbed docking windows, but they resist efforts to form user-selected groups. Also, the product doesn't understand nested data structures like an array of vectors, and its Quick Debug mode doesn't remember breakpoints from one debug session to the next.



Figure 3: Codelite 5.1.

DDD 3.3.12 is the GNU project's standard GUI front end to gdb and its other language debuggers. In many ways, it is a minimalist front end. It has single-button hotkeys for stepping through debugged program execution, but it lacks a toolbar with buttons for those commands. It displays nested data structures on a single line, which makes complex data items hard to understand. It sometimes gets stuck starting up, with an hourglass cursor that never changes back to normal.



Figure 4: Gnu DDD.

Eclipse is the Java IDE that, through continued development and its extensive ecosystem, has grown into an environment for development in many languages, including C and C++. It has resizable and detachable tabbed docking windows, excellent support for variable display, and an adequate code declaration/definition navigator. Its single button hotkeys and toolbar buttons for stepping through the debugged program are good. It also remembers breakpoints across debug sessions, but to find out how many times a breakpoint has been ignored, you have to issue the "info break" command in the gdb console window. (Note that while this example shows Eclipse using GDB, it supports many other compilers and debuggers. For example, cross-platform C/C++ development in Eclipse on Linux and Windows is also an option. Ed.)



Figure 5: Eclipse (Juno release) front-ending gdb.

GNU Emacs: As a long-time Emacs user, I wanted to like GNU emacs version 23.3.1's GDB mode. I like many of its features, but it's starting to show some age. It has multiple windows, some with tabs (to switch to other windows), but it doesn't support rearranging them. I like its display of single-level STL containers as arrays, but for the nested container: std::vector<std::vector<int>> it displays only the unhelpful {...} .



Figure 6: GNU Emacs' GDB mode.

KDevelop 4.3. is an open-source IDE for Linux, Solaris, FreeBSD, Max OS X, and other UNIX flavors. It has single-button hotkeys, but lacks toolbar buttons for stepping through the debugged program. Its simple variable and single-level STL container support is good, but displays that unhelpful abbreviation {...} for nested STL containers (see Figure 7). It does possess impressive menu of commands to navigate program symbols.



Figure 7: The KDevelop debugger.

Nemiver 0.9.1 "is an on-going effort to write a standalone graphical debugger that integrates well in the GNOME desktop environment," according to its creators. Predictably, it's open-source. It strives to maximize user friendliness in the debugger interface. It has single-button hotkeys and a toolbar with buttons for stepping through the debugged program. It pops up a convenient window for simple variables and arrays, but has no support for STL containers.



Figure 8: Nemiver.