RE: MACROS in gdb ???

[Eli Zaretskii <eliz at is dot elta dot co dot il>]

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.