This is the mail archive of the
mailing list for the GDB project.
Re: MACROS in gdb ???
- To: Aditya Chugh <Aditya at in dot huawei dot com>
- Subject: Re: MACROS in gdb ???
- From: jtc at redback dot com (J.T. Conklin)
- Date: 20 Mar 2001 16:51:18 -0800
- Cc: bug-gdb at prep dot ai dot mit dot edu, gdb at sourceware dot cygnus dot com
- References: <70EB682332F4D41187D6000629AE2C651AE3E4@mail.in.huawei.com>
- Reply-To: jtc at redback dot com
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> But does this mean that if we complile using GNU CC with both
Aditya> `-g' and `-O' options GDB will give us wrong results ??
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
* 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,