[Bug gdb/17520] New: structure offset wrong when 1/4 GB or greater

[Bug gdb/17520] New: structure offset wrong when 1/4 GB or greater

[dtaylor at emc dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17520

            Bug ID: 17520
           Summary: structure offset wrong when 1/4 GB or greater
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: dtaylor at emc dot com

When a structure member's offset is 1/4 GB or greater from the start
of the structure, GDB computes the wrong value.

When computing the offset of a structure member, GDB computes first
the BITS from the start of the structure, returns that as a 32 bit
signed quantity and then divides the result by 8.

While this can show up on 32 bit systems, it is especially bad on
64 bit systems.  We have systems with over 500 GB of memory and have
run into the problem.

Here's a short program that illustrates the bug.  The actual struct
where the problem was observed has over 250 members and is over 1/2 GB
in size.

#include <stdio.h>

struct big_struct
{
  char first[0x10000000 + 16];
  long second;
} big_struct;

int
main (int argc, char *argv[])
{
  printf ("sizeof (big_struct) 0x%lx,\n&big_struct %p,\n&big_struct.second
%p\noffset %lx\n",
      sizeof (big_struct),
      (void *)&big_struct,
      (void *)&big_struct.second,
      __builtin_offsetof(struct big_struct, second));
  return (0);
}

If I run it, the output is:

    sizeof (big_struct) 0x10000018,
    &big_struct 0x601040,
    &big_struct.second 0x10601050
    offset 10000010

But, in GDB 7.8:

    (gdb) p &big_struct
    $1 = (struct big_struct *) 0x601040 <big_struct>
    (gdb) p &big_struct.second
    $2 = (long *) 0xfffffffff0601050

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17520] structure offset wrong when 1/4 GB or greater

[jan.kratochvil at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17520

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat dot com

--- Comment #1 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
I Fedora carries for it the patchset:

http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-rhbz795424-bitpos-20of25.patch
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-rhbz795424-bitpos-21of25.patch
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-rhbz795424-bitpos-22of25.patch
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-rhbz795424-bitpos-23of25.patch
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-rhbz795424-bitpos-25of25-test.patch
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-rhbz795424-bitpos-25of25.patch
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-rhbz795424-bitpos-lazyvalue.patch

It was concluded that patching it before GDB is switched to C++ would be
fragile as there cannot be done easy sanity checking if the inferior types
width has not regressed.  With C++ one can wrap the offset types into
sanity-checked classes with overriden operators.

But the GDB switch to C++ takes too many years.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17520] structure offset wrong when 1/4 GB or greater

[sergiodj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17520

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergiodj at redhat dot com

--- Comment #2 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
Fedora has been carrying those patches for quite some time now, and I don't
remember seeing regressions because of them.  Maybe we could try to revive the
patches upstream...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17520] structure offset wrong when 1/4 GB or greater

[jan.kratochvil at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17520

--- Comment #3 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
I do not know how to verify they are correct.  That is there is no accidental
32bitvar=64bitvar; assignment or similar.  While that may be possible with some
LLVM static analysis I have been waiting for C++ which would make it easier. 
But then we are (were) all waiting on that approval of C++ switch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17520] structure offset wrong when 1/4 GB or greater

[dtaylor at usendtaylorx2l dot lss.emc.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17520

--- Comment #4 from dtaylor at usendtaylorx2l dot lss.emc.com ---
jan.kratochvil at redhat dot com <sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=17520
> 
> --- Comment #3 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
> I do not know how to verify they are correct.  That is there is no accidental
> 32bitvar=64bitvar; assignment or similar.  While that may be possible with some
> LLVM static analysis I have been waiting for C++ which would make it easier. 
> But then we are (were) all waiting on that approval of C++ switch.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

I don't care whether it's my patch or Red Hat's or someone else's, so
long as the bug is fixed.

The bug affects us and we want it fixed.  I would rather not have to
reapply the patch for each release.

If problems are found with the patch, generally they are easy to fix --
find the ooffending variable and change it from int to LONGEST.

I configured GDB with --enable-werror.  I started by changing everything
that I cou8ld find that was going to cause problems and then iterated
until everything built and ran with no regressions.

There a couple of places where I wasn't certain that it needed to be
converted, but I figured better safe than sorry.

If people are truly worried about it destabilizing GDB, then the right
approach is to put it in early -- to get as much mileage as possible on
it before the next release.

With regard to GDB moving to C++ -- it might happen, it has certainly
been talked about on and off for enough years, but as whether it will
ever happen -- who knows.  But, I am not going hold my breath.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17520] structure offset wrong when 1/4 GB or greater

[jburgess777 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17520

Jon Burgess <jburgess777 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jburgess777 at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.