While others have provided solid answers, I might as well add my two bits to close this thread. >>>>> "Aditya" == Aditya Chugh writes: Aditya> I found that one of the Makefiles I was using has CCFLAGS  = Aditya> -O2 -Wall.After removing the -O2 the problem seems to have Aditya> been resolved. Aditya> Aditya> But does this mean that if we complile using GNU CC with both Aditya> `-g'  and `-O' options GDB will give us wrong results ?? It can. There are several reasons for this. In some cases the compiler does not provide the necessary debug information to the debugger, in other cases the debugger does not interpret the debug info properly, and in other the debug info format is not rich enough to describe the optim- ization done by the compiler. When you are working on a problem, it really doesn't matter why (although on some targets it's possible to switch debug formats, for example from stabs to dwarf2), it's just something you have to adapt to. Aditya> Moreover the same code when run in Visual Studio 6.0 prints Aditya> correct values for u2IncarnId.Does this mean that the debugger Aditya> in Visual Studio 6.0 is better than GDB for optimized code ? I'm not familiar enough with Visual Studio 6.0 to say. Note that in some compilers, selecting debug options either disable outright or de- tunes the optimizer so the debug info and the code generated match. You could verify this by comparing the output of the VS6.0 compiler when the debug options is turned on and when it is turned off. Aditya> It comes as quite a sock to me ? Any more thoughts ??? with Aditya> sincere thanks, Aditya Only what's already been said. * It is possible to debug optimized code if you recognize that the source code isn't going to match the generated code. Variables may contain the wrong value, or perhaps be even optimized out of existance. * If it's not possible to debug optimized code, recompile your application without optimization. Some bugs might magically "go away" (actually, they're still lurking) since the code isn't the same. I find that algorithm botches usually show up bright and clear, it's the memory corruption bugs that evade detection. * And if you know what module(s) is botched, just recompile those. Hope this helps, --jtc -- J.T. Conklin RedBack Networks