GDB and debugging techniques

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