This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: c++/2039: gdb assumes 4 byte separation between 64 bit "long long" and "unsigned long long" stack allocated (not pointers) data member types within a C++ class
- From: Daniel Jacobowitz <drow at false dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 29 Nov 2005 16:08:01 -0000
- Subject: Re: c++/2039: gdb assumes 4 byte separation between 64 bit "long long" and "unsigned long long" stack allocated (not pointers) data member types within a C++ class
- Reply-to: Daniel Jacobowitz <drow at false dot org>
The following reply was made to PR c++/2039; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@false.org>
To: mstraub@gmail.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: c++/2039: gdb assumes 4 byte separation between 64 bit "long long" and "unsigned long long" stack allocated (not pointers) data member types within a C++ class
Date: Tue, 29 Nov 2005 11:05:44 -0500
On Tue, Nov 29, 2005 at 03:54:20PM -0000, mstraub@gmail.com wrote:
> >Release: GDB 6.2.1 (Bundled with SuSE 9.1)
You may want to try a more current release of GDB (e.g. a 6.4 release
candidate). However...
> Create a simple C++ class with two public "long long" data members.
> Create a property set method, setting both values to a unique value
> that occupies 64 bits. Use stdout print statements to print out the
> values of those variables immediately after setting them along with
> the address of those variables. Use the gdb print or display command
> to print the values after the stdout print statements. Doing this I
> consistently see the correct values printed to stdout, but incorrect
> values displayed in the debugger... Furthermore printing the address
> of those varaibles I see that the addresses are only 4 bytes apart...
> incorrect.
> I believe gdb is incorrectly guessing the offsets of data members in
> or around 64 bit integers.
GDB does not "guess" any offsets. They are always recorded in the
debug information, by the compiler. At least one version of GCC had a
bug that could produce this result.
Please attach a source file and compiled binary that shows this problem.
--
Daniel Jacobowitz
CodeSourcery, LLC