Channels ▼
RSS

Embedded Systems

13 Linux Debuggers for C++ Reviewed


Everybody has "favorite" information they use while debugging. My favorites include variable values and the call stack. And when looking at a program statement, the ability to see as much of its surrounding context as possible can really aid productivity. For these reasons, a GUI and resizable and detachable tabbed docking windows are valuable.

In Table 1, I rate these features using a scale from 1 to 5, with 5 being best. Like all such assessments, they are subjective (but I expect that where I gave low rankings to features, most developers would agree those products need improvement to be comparable to the other listed products).

Product

Stepping
keyboard

Stepping
mouse

Breakpoints

Tooltips

Variable
Inspection
Views

Navigate
Call Stack

Tab Docking
Windows

Totals

Affinic

5

5

4

2

3

5

3

27

Code::Blocks

5

5

4

2

2

5

3

26

Codelite

4

5

4

1

2

5

3

24

DDD

5

5

4

2

2

5

2

25

Eclipse

5

5

4

4

4

5

5

32

Emacs

3

5

2

1

3

5

2

21

KDevelop

5

5

4

3

2

5

2

26

Nemiver

5

5

4

2

2

5

2

25

Netbeans

5

5

5

2

5

5

5

32

QTCreator

5

2

4

3

5

5

2

26

SlickEdit

5

5

5

3

3

5

4

30

Totalview

5

5

4

1

5

5

1

26

Zerobugs

5

3

5

1

3

5

1

23

Table 1: Ratings of basic features, where 5 is best.

Less Used Features

These features I discuss here support operations we perform less often, so while important in choosing a debugger, they are somewhat less important — to me, at least — than the features in the previous section.

There are two frequent actions I used as indicators for this section: toggle breakpoint and run to line. One button hotkeys are ideal for these, but two buttons combinations work well enough here.

Sometimes you step over a function call and then, having seen its return value, you wish you'd stepped in. For that situation, the ability to set the next statement to be executed back one or more lines by moving the instruction pointer saves the trouble of rerunning the program. Moving the instruction pointer forward to skip a program statement is another use of set-next-statement, though less common.

At other times, you might like to know how the program (or a function in it) would act if a variable had a different value. The ability to change the value of a variable can save you from having to edit, recompile, and perform the sometimes complex steps to duplicate your program's state. Every variable window should support this use.

Some programs implement data structures complex enough that the debugger's default variable value display isn't very helpful. Examples include hand-crafted linked lists and tagged unions. Certainly, you can click-click-click your way through a custom linked list, or look at a union's tag field to see which union member is active, but that extra effort can break the concentration you need to diagnose a really tough bug. For frequently used data, some programmers (including me) find it worthwhile to write a bit of custom code to do that work automatically. Of course, your debugger must support this kind of customization. These customizations must be in separate files, so changes don't have to be merged as new versions of the debugger are released. Also, these customizations are designed for data structures the debuggers couldn't possibly know about.

I don't often use the ability to load a core dump, but it's invaluable for those (thankfully) rare crashes that only seem to happen at customer sites.

One non-debugging feature I like in a debugger is the ability to click on a symbol and have the file and line with the declaration or definition appear. Ideally, the debugger should present you with a choice of declaration or definition.

Customizing the keyboard bindings is something I typically do not do, but some of my coworkers adamantly insist that this is an important feature. There are a few capabilities that, together, make this ability fully featured. In order of importance, they are binding debugger commands to new keys, importing/exporting a complete set of bindings, and emulating other debuggers' key bindings.

Table 2 summarizes how the various products scored on all of these less used features.

(5 is best)

Toggle
breakpoint

Run to
line

Set Next
Statement

Change
Variable Value

Custom
Variable Display

Load
Core Dump

Jump to
Declaration/
Definition

Easy build
and debug

Customize
Keyboard

Totals

Affinic

4

3

1

2

1

1

3

1

1

17

Code::Blocks

5

5

5

1

3

1

2

5

1

28

Codelite

5

5

5

1

4

5

5

5

1

36

DDD

4

1

1

1

1

5

3

1

1

18

Eclipse

5

5

5

5

5

5

4

4

4

42

Emacs

4

1

1

3

1

1

2

3

2

18

KDBG

5

5

5

1

1

5

1

1

3

27

KDevelop

4

5

5

1

3

5

1

1

3

28

Nemiver

5

5

5

4

1

5

1

1

1

28

Netbeans

5

5

1

5

5

5

5

5

5

41

QTCreator

5

5

5

5

1

4

5

5

4

39

SlickEdit

5

5

5

5

5

5

5

5

5

45

Totalview

5

5

5

5

5

5

1

1

1

33

Zerobugs

3

1

1

5

2

5

2

1

3

23

Table 2: Ratings of lesser-used features (5 is best).

Conclusion

None of the debuggers I tested was perfect. Not surprisingly, every product had some unexpected weakness that many of the others didn't share. However, most of the debuggers supported the bulk of the features I look for. The only debuggers with resizable and detachable tabbed docking windows are Eclipse, Netbeans, and SlickEdit. All are fine choices. For now, I'm using Eclipse. Its engineering isn't as good as TotalView's, but for my uses, it makes the best overall compromise between UI and engineering — it has both docking windows and good variable display.

TotalView gets a special mention for its excellent multithreaded and multiprocessor support, and when it gets tabbed docking windows, it'll be a top contender. Its multithread support is so far ahead of the field that if that were my principal need, I'd look no further.

I hope that if you're using other products, this comparison will provide you incentive to experiment and possibly find a tool that better serves your specific needs.

Test Platforms

At home, I tested on Canonical Ltd. Ubuntu 12.04 64-bit on VMware. At work, I tested on Ubuntu 10.04 64 bit on a quad-core AMD system. The Zerobugs binary is available for Ubuntu 11.10, so that's where I tested it.

Ubuntu 10.04 installs gdb version 7.1-1ubuntu2, which is sometimes extremely slow. Fortunately, recent versions correct that. I used gdb 7.5.1.

I installed the STL pretty printers for gdb. They require Python support, so if you compile gdb from source, you'll have to install python-dev and run gdb's pre-build configure script with the --with-python switch.


Howard Rubin has been programming professionally for more than 20 years and lives in Boulder, Colorado. He is on the C++ development team at Intio, a vendor of 3D medical imaging systems.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video