RE: MACROS in gdb ???

[Aditya Chugh <Aditya@in.huawei.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2608 bytes --]

Title: RE: MACROS in gdb ???





Hello Jtc,
Many thanks for your help.
The target I'm using is a Linux machine 
running kernel version 2.2.16-22(Red Hat Linux release 7.0)
and the version of gdb is 5.0.


Also the gdb output looked like this....?
(gdb) p u2IncarnId
$2 = 0
(gdb) n
(gdb) p u2IncarnId
$3 = 1
(gdb) p &u2IncarnId
Address requested for identifier "u2IncarnId" which is in a register.
(gdb)


I found that one of the Makefiles I was using has
CCFLAGS  = -O2 -Wall.After removing the -O2 the problem seems to have been resolved.


But does this mean that if we complile using GNU CC with both `-g'  and `-O' options
GDB will give us wrong results ?? Moreover the same code when run in Visual Studio 6.0
prints correct values for u2IncarnId.Does this mean that the debugger in Visual Studio 6.0
is better than GDB for optimized code ? It comes as quite a sock to me ?
Any more thoughts ???
with sincere thanks,
Aditya




-----Original Message-----
From: jtc@redback.com [ mailto:jtc@redback.com ]
Sent: Tuesday, March 20, 2001 4:12 AM
To: Aditya Chugh
Cc: bug-gdb@prep.ai.mit.edu; gdb@sourceware.cygnus.com
Subject: Re: MACROS in gdb ???




>>>>> "Aditya" == Aditya Chugh <Aditya@in.huawei.com> writes:
Aditya> I am not sure this is the right forum for a question on gdb.


I have culled the 'cc' list to the most relevant mailing lists.


Aditya> I am a Newbie as far as gdb is concerned.  But I have been
Aditya> struggling with this for quite some time and would sincerely
Aditya> appreciate any help.


Aditya> But after processing this macro the value of u2IncarnId
Aditya> changes unexplicably ????


You don't mention what target you're using or what optimization level
was used when you compiled the files.  But the symptoms you describe
often occur when debugging optimized code.  


For example if a register is being used to hold a value and then that
value is no longer needed in the rest of the function, a compiler may
choose to use that register for an unrelated value.  This can make
debugging a bit of a challenge, but looking at a disassembly of the
function or recompiling the system with no optimization can be used to
help diagnose the problem.


It helps to have a somewhat "flexible" attitude when it comes to
debugging optimized code.  A rigid interpretation of results will
lead to frustration.


Aditya> If I am missing something obvious please forgive me. I have
Aditya> spent the whole day trying to figure out where I am going
Aditya> wrong.


I hope this helps.  


        --jtc


-- 
J.T. Conklin
RedBack Networks