October 29, 2009, 11:41 AM — gdb 7.0 matters to you: that's the theme for the week. Even if you write in a language that fits gdb poorly, and even if you wouldn't use a debugger when coding in C (which you don't do), and even if you'd use a different debugger when debugging (which you don't do) in C (which you don't do), gdb still affects your world.
The previous installment of "Smart Development mentioned refined facilities for execution management: running an application backwards, scripting its analysis, and so on. Authors of high-level languages and their extensions will find these techniques particularly useful for tracking down conflicts between libraries. Moreover, while 7.0's scripting language is Python, scriptability is likely to help with development of all C-implemented high-level languages: scripts can help keep track of language-specific data structures that are otherwise hard to visualize and monitor.
My thanks to Michael Snyder who helpfully pointed out this tutorial on gdb's record-and-playback capabilities.
"Non-stop debugging"
Also important for language maintainers is gdb's growing support for 64-bit computing. 7.0 is native for MinGW and Darwin.
The biggest architectural news, though, has to do with multi-core computing. While it's been clear for four decades (if for reasons that sometimes changed from year to year) that we're headed to a computing future that involves co-operation betwteen multiple processing nodes, we remain at a relatively primitive level of implementation. Working programmers struggle with concurrency and dependency topics that were believed solved in pre-Web times.
gdb's "non-stop debugging", new with 7.0, is a small but significant step forward to getting multi-cores right. Suppose you have a multi-threaded application. Before 7.0, gdb managed all its threads together: to pause one thread and examine the program state, you necessarily paused all threads.
"Non-stop debugging" gives programmers a new choice: we can pause one thread of interest, while letting others continue to process events, retrieve a database answer, compute a difficult result, or otherwise do what they should. It feels like the anatomical analogue of moving forward from autopsies to diagnostic surgery on a living patient. To see a situation in functional context can be crucial.
"Non-stop debugging ..." fully explains gdb's facility, including its use in remote debugging and MI (machine interface). Understand: this is only the beginning; while "non-stop" is already a huge aid in some kinds of multi-threaded work, there are still many, many conveniences left to build before we are handling multi-cores as well as we should.
