Latest gdb important milestone
Grey-bearded debugger offers plenty
GNU released gdb 7.0 at the beginning of the month. This is an important milestone for all of us.
It's important for several reasons, even if you rarely use debuggers (as I do, on current projects), work mostly in high-level languages (as I do) and/or Java, are so unfamiliar with gdb that you don't know where to begin with it, or use gdb so much and so instinctively that you don't need for it to change. As we'll see over the next few installments of "Smart Development", Version 7.0 is a great time to learn gdb.
Even if you don't touch gdb directly, it affects your world. Just as you benefit from open-source even without reading the source (through the social guarantees of security, for example), your development environment is a healthier one when you know you can put your hands on a reliable, highly-portable, very powerful debugger if you get into trouble.
"How did I get here?"
'Ever been in a debugging session, and realized, "Uh-oh: I needed to pause ten steps earlier; how am I going to find out what the variables were?" You're not alone. With 7.0, gdb fully supports "reverse execution" or "reverse debugging"): you can back your program up. gdb gives all the usual control over reverse execution: you can single-step, you can step either into subroutines or over them--backwards--you can back up until you reach a breakpoint, and so on.
That's not all. 7.0 also makes it easy to record and playback a session. This gives you both the opportunity to read the log, to learn what you did to arrive at your location, and also to retrace some or all of your path.
Moreover, you can script gdb's capabilities with Python, now. If you need to look at the contents of a complicated data structure through time, during the execution of your application, you now can code in high-level Python a little report that understands how to display the content usefully, then invoke that function during your session. Script it once, and you never again have to slow down to figure out the keystrokes to look at the contents of the location addressed by the third element of the content of ...
This is only a fraction of what 7.0 provides. I'll follow up throughout the week with more examples of how slick gdb has become.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.
reverse debugging tutorial online
There is an online tutorial for using gdb reverse debugging and process record/replay athttp://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial
Debuggers?
An alternative to an excellent debugger is excellent design derived from outstanding requirements. The better these are the less likely a debugger needs to be invoked. IMHO many of the root-causes have been distilled down to issues in design or requirements. Any debuggers available for these two important phases....?Debug design? Requirements?
Yes and no. No, there aren't executable debuggers for the overwhelming majority of "requirements" and "designs". Yes, though, there's a vast literature on techniques to formalize and automate analysis and design.
Thanks for raising the question. I'll make a point of covering it in more detail in November 2009. For now, I'll simply offer the tip that the smartest single thing I know to do is to bring in testers and documenters as early in a development cycle as possible. Applications that can't be verified or explained ... well, that stacks the odds against success.