GDB and debugging techniques

[Alan Dayley]

At 04:00 PM 2/9/01 +0000, you wrote:
>Ive found that if you understand the sourcecode, often *adding* lines
>that output information to a file somewhere as the program runs beats
>the snot out of any "after the fact" debugger. Doing it that way makes
>it possible to spot verify any area of a program ...

In embedded systems debug outputs can change the behavior of the system, 
especially when multi-tasking.  But then, a debugger can change the 
behavior of the system too.  Embedded can be so fun!

Serious debugging, looking at memory, viewing structures, stepping through 
the code can save LOADS of time.  It is one of my cardinal rules: Always 
step through new code at least the first time you run it.  I can save loads 
of time, especially on the dumb errors like:

if (foo = 0)
{
...
}

Sometimes outputs are all you can do, especially if you don't have a good 
debugger or emulator.

>Whats your opinion on this approach to debugging? (obviously you dont
>want those code snippets showing up in a production release, however!)

Make sure you bracket the the debug code with "#ifdef DEBUG" or something 
like that (whatever your language allows) and have a debug build and 
release build in your makefile.

This is basic stuff.  I like to share, though.

Alan