Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain <mec at shout dot net>]

For concreteness, suppose that the user has a structure with
two integers in it, and sizeof(int) is the natural register size
(which of course has been the design principle for C for decades).

  struct point
  {
    int x;
    int y;
  };

  struct point p1 = { 1234, 5678 };

Everybody's favorite output is:

  (gdb) print p1
  $1 = {1234, 5678}

Right now gdb can print lies:

  (gdb) print p1
  $1 = {1234, -8675309}

Incorrect data is much worse than no data at all.  Instead of iterating
over registers, I would like gdb to print:

  (gdb) print p1
  $1 = {1234, <unknown>}

I'm not stuck on "<unknown>".  It can be any string which indicates the
debugger can't tell the user what's in p1.y.

The heinous part is that gdb *knows* it is pulling some register value out of
its ass for p1.y.  I understand that on some targets, gcc and gdb might agree
on register number allocation (ignore for the moment that there are other
compilers besides gcc).  Okay, for targets where we have a guarantee about
that, then enable sequential register access.  But i686-pc-linux-gnu is
definitely not such a target.

Somewhat worse is:

  (gdb) print p1
  $1 = <unknown>

If the compiler tells us that an 8-byte variable is in a 4-byte register,
I feel comfortable printing the first 4 bytes.  But I would actually
printing no values to printing incorrect values.

If a debug format has enough information to print {1234, 5678},
that's great.  And we should ask gcc to give us that much information
in all the formats we can get to.  If we're lucky, then stabs+ will
become obsolete faster than people start seeing more multi-register
variables.  :)

Michael C