GDB and debugging techniques

[plug@arcticmail.com]

I've seen some people do

if ( 0 == foo )
{
    ...
}

in C to try to avoid this particular "dumb error."
(Just try compiling using "if ( 0 = foo )" )

Hmmm.  Perhaps Pascal's ":=" thingie ain't so
stupid after all...


D

* On Fri, Feb 09, 2001 at 09:57:52PM -0700, Alan Dayley wrote:
> 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