bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GDB 5.1 problem printing member variables


From: Gary Kroening
Subject: GDB 5.1 problem printing member variables
Date: Tue, 22 Jan 2002 12:18:22 -0600

Hi,
I originally sent this to Jim, but then noticed in the gdb README info
that I should send it to bug-gdb -- sorry, Jim!

Per the explanation in the README file, here's the gdb banner:

metis:prom_efi> ~/tmp/gnu/gdb-5.1/build/gdb/gdb \
~/workarea/osprey1.0/targia32_ia64/medusa/medusa 
GNU gdb 5.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) 


As described below, I used 'configure' with no options, and the problem seems
common to at least IA32 (i*86), IA64, and MIPS.

-------- Original Message --------
Subject: GDB 5.1 problem printing member variables
Date: Fri, 18 Jan 2002 13:33:56 -0600 (CST)
From: Gary Kroening <address@hidden>
To: address@hidden
CC: address@hidden, address@hidden

Hi Jim,
My name is Gary Kroening (address@hidden phone 651-683-5277). I work at
SGI, currently doing simulation of IA64 machines. I hope it's
appropriate to contact you on this topic, but please let me know if
I should take a different approach. I found your name in the file
gnu-v3-abi.c in the GDB 5.1 source.

I'm wondering if you know how to fix or work around a problem that
seems to be an incompatibility between gcc/g++ and gdb. I'll try not
to be too long-winded here, in case you've already answered this for
someone else. Please ask if you need more info.


Summary:
--------
I can't print member variables of objects generated by g++ v3.x,
using the "print" command in gdb. I can print local variables,
and print the "this" pointer, but gdb can't seem to dereference the
this pointer. I get:

(gdb) p this
$1 = (IA64HwCpu * const) 0x10fbe5b8
(gdb) p *this
Value can't be converted to integer.
(gdb) p fault      #<==== fault is a data member of IA64HwCpu class.
Value can't be converted to integer.


Note that if I debug an executable generated by g++ 2.x (2.96 in this
case), things work OK with both an old gdb 4.17 and gdb 5.1.


More details:
-------------

Background: I'm trying to get compatible versions of gcc/g++ and
gdb running on the following platforms: IA32, IA64, and MIPS. I've
been able to get gcc 3.0.3 to compile my simulator on IA32 and MIPS;
I have trouble getting gcc 3.0.3 itself to build on IA64, so I'm using
gcc 3.0 there. The trouble seems to be for all versions of gcc 3.x.

When I first tried to debug programs with the old version of gdb we
had around (4.17), it died trying to load and debug executables from
the new gcc 3.x compilers. So I downloaded gdb 5.1. I configured and
build it like the README file said:

cd $GDB_SRC
mkdir build
cd build
$GDB_SRC/configure
gmake   <=== tried make and gmake, gmake seems better


I don't know anything about gdb design, but I've done some
investigating on the problem. The message is coming from values.c,
in the function unpack_long().

Here's what happens when I type "print *this":

If I'm debugging a g++ 2.x executable, unpack_long() is called twice,
with the following TYPE_CODEs:

TYPE_CODE_PTR
TYPE_CODE_PTR

(It actually gets called a few more times after this.) If I'm debugging
a g++ 3.x executable, I see:

TYPE_CODE_PTR
TYPE_CODE_STRUCT

unpack_long() doesn't have a case to handle TYPE_CODE_STRUCT, so it
bails out. 


I tried to learn a little more about what's happening on the second
call to unpack_long(). For both 2.x and 3.x, unpack_long() is called
by value_as_pointer() (also in values.c). When debugging the 2.x program, 
value_as_pointer() is called by gnu-v2-abi.c::gnuv2_value_rtti_type(),
and for the 3.x program, gnu-v3-abi.c::gnuv3_value_rtti_type().


........

>From there, I tried a bunch of things such as hacking unpack_long(),
etc., but I don't know what I'm doing. Also, my brain started to fail,
since I was running gdb on gdb on my simulator, which was simulating
Linux!


I hope I've given you enough info to go on, but please let me know if
I should send more info, or contact someone else. This is the first
time I've tried to resolve a gdb problem.

Thanks.
Gary



reply via email to

[Prev in Thread] Current Thread [Next in Thread]