"Debugging" is how many of us spend a sizable slice of our time as developers. Several changes in the last year, including significant releases of software and books, make it a good occasion to examine what's available to boost our productivity.

Timely Book

The theme for January 2009 here at Linux Developer Network is "application development." It's widely accepted that "[d]ebugging is the most difficult and costly phase of software development." While we're skeptical of much conventional wisdom having to do with debugging, and will return to the subject during the coming year, we can certainly agree for this month that anyone who debugs ought to do so efficiently.

Debugging is "the process of 'diagnosing the precise nature of a known error and then correcting it'," according to a formulation already in print by 1976. Written help in that process, at least for the Linux world, has centered for some years on David Agans' Debugging Rules! Web site and Debugging book, first published in 2002, and available in revised form from 2006. Debugging is slender, general-purpose, and largely language-neutral, emphasizing the logic and analysis of debugging situations more than particular tools and their specific techniques.

Tutorials commonly read by Linux programmers have generally complemented Debugging by focusing on detailed recipes for use: launch this particular debugger by typing this command, and so on. As of September 2008, there's a fresh treatment of debugging that operates in the middle: The Art of Debugging combines sage general strategies for diagnosis and repair with an abundance of screen-shots and working code.

It's useful to sort application developers working on Linux into these large categories of language focus:

• C and C++
• Java
• Other

Debugging tools once fractured along the same lines, with C/C++ programmers using gdb, and the Java realm mostly divided between Eclipse and NetBeans. The rest of us, often using high-level languages (HLLs) like Perl, Smalltalk, Forth, Tcl, and so on, generally relied on language-specific tools.

While this broad picture is still visible in 2009, the boundaries have become more complex and often blurrier. Still, it's apt that the subtitle of The Art of Debugging is "... with GDB, DDD, and Eclipse", because those three tools cover a great expanse of the territory of Linux debugging. Here are the essentials of what you should know about them:

GDB, DDD, and Eclipse

gdb "is the standard debugger for the GNU software system." It works well on a dizzing array of chip architectures, and supports variants that handle source in C, C++, Fortran, Assembler, Ada, and quite a few other languages. Richard Stallman first wrote it in 1986, and it shows every sign of vitality sufficient to take it another two decades.

gdb is character-oriented: to make things happen with gdb, or to view its results, you type on the same 24x80 character screen (or a generalization) that became standard during the 1960s. DDD seasons that base by wrapping a graphical user interface (GUI) around it.

Eclipse is a whole platform, but for the purpose of this column, we'll focus on its realization as a debugger. Eclipse originated in the Java world, and is most dominant there. A symptom of the robustness and success of these tools, though, is that they can be combined in a variety of ways: gdb can be plugged into Eclipse, DDD supports Java debugging, and so on.

What About the Rest of Us?

All that we've written above is context: the real point to emphasize is that it's time to revisit these basics to enrich your own debugging practice, especially if most of your work is not in C/C++/Java. The Art of Programming expertly introduces gdb, DDD, and Eclipse, and each of these tools has made strides in the last year in supporting the HLLs on which we concentrate. In fact, the final chapter of The Art of Programming concludes with sections on debugging Perl, Python, SWIGged code, and assembly language!

This only begins the progress with debuggers that 2008 brought developers:

• The Eclipse-based erlIDE integrated development environment (IDE) reached its first beta release in November 2008.
• NetBeans, which is roughly equivalent to and in competition with Eclipse, can do slick operations with Ruby, Python, PHP, JavaScript, and more.
• proprietary debuggers for all sorts, including Version 5.0 of ActiveState's Komodo multi-language IDE, came out during the year.
• The Developer's Guide to Debugging came out the same week as The Art of Debugging. While the former's focus on C/C++ makes it less pertinent to this column than the latter, we admire the precision of its coverage of such ancillary tools as quantify and dmalloc.
• And much more.

The New Year is a great time to learn new tools and techniques that'll pay off in the months to come. Debugging is a particularly favorable investment to make, because it can consume so much time when done inefficiently. Wherever you start, there's plenty to learn:

• If you're already familiar with command-line gdb, try out a couple of its dozen different GUI front ends to see how they fit you.
• If you work in a non-traditional HLL, test the latest Eclipse plugin or commercial IDE for your language.
• If you're already good with Eclipse or NetBeans, try a few new plugins that solve problems in static analysis, UML management, syntax completion, test coverage, or other advanced areas.
• If it's been a while since you've read a book on debugging, you owe it to yourself to catch up with one of the latest treatments.

We'll return to the subject of debugging later in the year with a few of our own ideas. Until then, make sure you get all the help you need to make the best of your own programming. If you have a question about the capabilities of your favorite language or debugger, ask in the Comments section below.