Re: MACROS in gdb ???

[jtc at redback dot com (J.T. Conklin)]

While others have provided solid answers, I might as well add my two
bits to close this thread.

>>>>> "Aditya" == Aditya Chugh <Aditya@in.huawei.com> 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