Re: GDB 5.1 problem printing member variables

[Andrew Cagney <ac131313 at cygnus dot com>]

Um, er,

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

Can you try this on a current gdb 
(http://sources.redhat.com/gdb/current) and if the problem is still 
present, at least create a bug report (http://sources.redhat.com/gdb/bugs).

Andrew


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

I'll see what I can do about this.

Andrew


> 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 <gfk@sgi.com>
> To: jimb@redhat.com
> CC: gfk@sgi.com, tk@sgi.com
> 
> Hi Jim,
> My name is Gary Kroening (gfk@sgi.com 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
>