November 08, 2009, 12:02 PM — Recent posts emphasized the new capabilities the 7.0 release of gdb provides: it manages processes more adeptly, it works on more hardware, and so on. Even though gdb is older than all but very few applications, it has continued to improve.
It's far from done, though. One of the important features to learn about gdb, in fact, is recognition that it's more platform than product. By that I mean that its highest value is not necessarily to polish and refine particular functions so they're easy to use, but to make them possible so that innovators can explore them. gdb is in active competition for daily use with several other open-source and proprietary products, such as Intel's debugger. The latter is actually superior in a number of ways for multi-core debugging, for example, an emphasis of the previous post in this series.
Where gdb shines, though, is its openness. While quite a few of its features remain only half-baked, the nice thing about them is they work together. If you need remote debugging, on an obscure chipset, with reverse-execution capabilities, which inspects data drawn from multi-byte character sets, gdb is probably your best bet: although it's likely to show a few blemishes in such a situation, it at least "shows up to work", so you don't have to wait until proprietary vendors deliver.
More than many programmers realize, gdb is an experimental testbed for a wide variety of projects. It's good to learn gdb if only because so many other innovative initiatives, such as LLVM and Eclipse, depend on it, in one way or another. gdb tracks significant new technologies; it's feasible to debug JITted code with it, for example.
I personally only use gdb sporadically, and I certainly don't keep up with it well enough to understand where it's going after 7.0. I'm often frustrated by gdb's relative paucity of documentation, including "roadmaps" of plans for future maintenance and enhancement. I've seen enough of its history, though, to be confident it'll be around for many years to come, often at the leading edge of new work in chips, compilers, and debugging.
