Debugging Tools
Wednesday, June 2, 2010 at 8:26PM You never realize how much you use your debugging tools (even ones you consider to be mediocre) until you don’t have anything but printf.
Debugging tools such as your debugger, profiler, memory allocation/deallocation tracker, etc are some of the most useful tools in the development process of any project more complex than Hello, World. I have often found myself cursing the tools, either because they couldn’t operate in a certain situation (debugger that won’t work when crossing the application/driver boundary), or because they would cause strange behavior in other running tasks (mostly due to timing issues); but lately I have moved to a new system (Lynx) that doesn’t have all the tools that my previous system (VxWorks) had. There are tools, but other than strait gdb, it’s an optional suite that is an additional license on top of the Lynx license. VxWorks requires the tool suite in order to work with the system, which makes the decision to purchase the tools easier for the corporate types who hold the checkbook.
Using gdb on Lynx is a pain for many reasons, mostly due to having to be local to the hardware, which means you generally don’t have any source code available. I also have not had much luck with the server variant of gdb.
For VxWorks, I have only used the Tornado suite of tools for long enough to pass any judgement on them. Tornado also includes the RTI tools, which give you many different ways of viewing the system; such as memory allocation tracking, profiling, coverage tracking, and an oscilloscope type view of data in the system. All these tools give you the ability to look at a problem from different angles and see why things are not working, and possibly how to fix them. These are tools I now sorely miss on Lynx.
The lesson here I guess is: don’t bitch too loudly about your tools. At least you have them.
Tools, VxWorks, lynx in RTOS, development 
