Those of you who write perfect programs the first time around may leave the room. Now for the rest of us, what debug tools do you use?
The crude but effective printf (for C and C++) is probably at the top of everyone’s list. Variations include watch variables in debuggers and control panels for graphical environments like National Instruments’ LabVIEW, but the idea is the same—see what the program is doing and then figure out what’s going wrong.
Unfortunately, printf is often the only technique many programmers know about when it comes to debugging. The problem is that the technique is so easy, at least initially and for small projects, that other debugging tools are frequently overlooked. Some programmers take advantage of conditional compilation so debugging support can be maintained with the program. But the typical approach still adds and deletes printf statements.
Many debuggers provide sophisticated watch windows and macro support that are designed to expose the interior of a running application. These aids are invaluable. Like text editors and the integrated development environments (IDEs) of old, however, they’re distinctly unique.
This isn’t an issue in dealing with a particular debugger for a project, though it makes migration to a new debugger frustrating and tedious. The lack of consistency between debuggers often leads to the least common denominator, the GNU GDB debugger, at least for C/C++.
In the embedded world, collections of open-source tools from different vendors generally include the same compilers and linkers, but a proprietary package often replaces the debugger. This is frequently the case when vendors of development tools migrate to the Eclipse IDE, which is common these days. In this case, the original debugger comes along for the ride.
The printf approach to debugging is essentially the poor man’s version of a trace tool. Developers are usually aware of trace tools, but they typically target tracing system level interfaces. Likewise, hardware trace probes are well known to hardware developers but tend to be overlooked by software developers as useful application debugging tools.
HARDWARE PRINTF
Another overlooked tool, the hardware printf, takes advantage of unused hardware resources such as I/O ports that can be hooked to a logic analyzer to deliver a hardware trace facility. Alternatively, the outputs can drive LEDs or other user interface hardware. This approach gets more interesting in dealing with flexible hardware architectures such as FPGAs and Cypress Semiconductor’s PSoC 3 and 5 microcontrollers (see “Field Programmable I/O Augments 8-Bit Microcontroller”). In these cases, internal signals can be made available without software interaction. Likewise, the ability to add custom logic allows trace information to be massaged.
WORK IN PROGRESS
One interesting emerging option is the Eclipse project’s Debugger Services Framework (DSF). DSF-GDB is building the GDB debugger on DSF and adding new features for reverse debugging, multiprocess, and non-stop debugging support.
It will be the basis for the current GDB 7. DSF provides a modular approach to the debugger and should provide extensibility similar to the rest of the Eclipse framework. This should permit a more extensible debugger while enabling the kinds of extensions in proprietary debuggers.
So if you don’t initially spawn perfect programs, let me know what your debugging regimen is like and how your debugger and trace tools fare against the competition.
ECLIPSE • www.eclipse.org