MACROS in gdb ???

MACROS in gdb ???

[Aditya Chugh]

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

Title: MACROS in gdb ???





Hello ,
I am not sure this is the right forum for a question on gdb.I am a Newbie as far as gdb is concerned.
But I have been struggling with this for quite some time and would sincerely appreciate any help.


I am trying to use gdb for a C program which makes heavy
use of C macros. 


The function ldpCreateIncarn() is called with parameter u2IncarnId set to 0.


UINT1 ldpCreateIncarn (UINT2 u2IncarnId)
{
   UINT1 u1HoldPrio;


   LDP_ASSERT(u2IncarnId == LDP_CUR_INCARN);
   if ( LDP_INCARN_STATUS(u2IncarnId) == ACTIVE )  
   {
       return LDP_FAILURE;
   }


   gblTmrMemChkId = 1;
   gblSNMPMemChkId = 1;
.
.
.
}


After call to LDP_INCARN_STATUS(u2IncarnId) the value of 
u2IncarnId MYSTERIOUSLY changes to 1.LDP_INCARN_STATUS is a macro defined as follows


#define LDP_INCARN_STATUS(x) (gLdpInfo.LdpIncarn[(x)].IncarnRowStatus)


...it only reads the status from a global data-stucture and checks to see if it is ACTIVE. It does not change the value of "x" in any way.

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



Also in this function I have some other Macros like


INIT_LBL_MGR_INFO(u2IncarnId)
which are defined as
#define INIT_LBL_MGR_INFO(x) gLdpInfo.LdpIncarn[(x)].LdpLblMgrInfo.u4NumGrpsActive = LDP_ZERO;


At the time of entering such macros u2IncarnId is set to 0 but after processing the macro its value cahnges to 168 !!


(gdb) p u2IncarnId
$19 = 0
(gdb) n
(gdb) p u2IncarnId
$20 = 168


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

Re: MACROS in gdb ???

[J.T. Conklin]

>>>>> "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

RE: MACROS in gdb ???

[Aditya Chugh]

[-- 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

Re: MACROS in gdb ???

[J.T. Conklin]

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

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

RE: MACROS in gdb ???

[Eli Zaretskii]

On Tue, 20 Mar 2001, Aditya Chugh wrote:

> (gdb) p &u2IncarnId
> Address requested for identifier "u2IncarnId" which is in a register.

Alternatively, "info address u2IncarnId" will tell you explicitly
where the variable is stored.

> But does this mean that if we complile using GNU CC with both `-g'  and `-O'
> options GDB will give us wrong results ??

No, it just means that debugging optimized code should be taken with a
grain of salt.  In particular, you should be very suspicious about
values of variables that are in registers: verify them with
independent evidence, such as (in this case) the info about the
arguments with which the function was called (type "info args"), or
evaluation of equivalent expressions which use only memory-based
variables.

> 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 ?

Part of the blame lies with the compiler (which doesn't leave enough
info for the debugger to deal with register variables), part of the
problem is in the debugger.  As ABIs evolve, GDB development needs to
catch up, and it takes time.  (Note that when you debug with Visual 
Studio, you don't replace the debugger alone, you also use a different 
compiler.  So the comparison with GDB alone is not really fair.)

Also note that GCC doesn't change its code generation when it sees -g,
so you are actually debugging the same code which will run in the
production version.  Other compilers lower the optimization level or
disable optimizations completely when building a debug version, so you
are debugging a totally different code.  This is an important feature
of GCC and GDB, but it does come at a price.

(This is why I think your ``solution'' of disabling optimizations is
Bad Idea: you are debugging a program which is very different from the
production code that will actually run on your target system.)

One possibility to try is to compile your program with -gstabs+
instead of -g (unless your GCC is already configured to do that by
default).  That provides more elaborate debug info for GDB to work
with, but I'm not sure it will help in this particular case.

Re: MACROS in gdb ???

[Kevin Buettner]

On Mar 20, 11:23am, Eli Zaretskii wrote:

> (This is why I think your ``solution'' of disabling optimizations is
> Bad Idea: you are debugging a program which is very different from the
> production code that will actually run on your target system.)

A compromise solution is to only recompile those files that you think
you'll be actively debugging with a lower optimization level.  You
are still debugging a program which'll be different than the production
code, but only parts of it are different.

Also, it should be noted that it's frequently easier to just turn off
optimizations at times when the debugger is *really* needed and then
turn them back on again once the problem is solved.  (I usually make
an attempt at figuring out the problem in the optimized version; but
sometimes either there just isn't enough debug information or the
behavior is too confusing.  At that point, I'll recompile the source
file in question with lower optimization.)

Kevin

Re: MACROS in gdb ???

[Eli Zaretskii]

On Tue, 20 Mar 2001, Kevin Buettner wrote:

> I usually make an attempt at figuring out the problem in the
> optimized version; but sometimes either there just isn't enough
> debug information or the behavior is too confusing.  At that point,
> I'll recompile the source file in question with lower optimization.

Yes, I agree: turning off optimizations should be the last resort, if
debugging optimized code is so confusing that you can't figure out
what's going on.

I find that it is usually unnecessary to turn off optimizations,
except in very rare cases.

Re: MACROS in gdb ???

[Daniel Berlin]

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

Aditya Chugh <Aditya@in.huawei.com> writes:

> 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 ? 
Right now?
Quite possibly.


Optimized debugging support in GDB is only really possible through
fully supporting things we don't fully support yet.
--Dan