public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: brobecker@gnat.com, kettenis@chello.nl
Cc: gdb@sources.redhat.com
Subject: Re: 8-byte register values on a 32-bit machine
Date: Sat, 01 Mar 2003 20:57:00 -0000	[thread overview]
Message-ID: <200303012057.h21KvFv26400@duracef.shout.net> (raw)

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

             reply	other threads:[~2003-03-01 20:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-01 20:57 Michael Elizabeth Chastain [this message]
2003-03-01 22:46 ` Mark Kettenis
  -- strict thread matches above, loose matches on Subject: below --
2003-03-14 16:27 Michael Elizabeth Chastain
2003-03-13  4:18 Michael Elizabeth Chastain
2003-03-13 17:05 ` Andrew Cagney
2003-03-12 19:09 Michael Elizabeth Chastain
2003-03-12 20:47 ` Andrew Cagney
2003-03-02 16:59 Michael Elizabeth Chastain
2003-03-12 15:35 ` Andrew Cagney
2003-03-12 15:51   ` Daniel Jacobowitz
2003-03-12 16:57     ` Andrew Cagney
2003-03-12 17:01       ` Daniel Jacobowitz
2003-03-12 18:15         ` Andrew Cagney
2003-03-12 18:29     ` Andrew Cagney
2003-03-12 18:35       ` Daniel Jacobowitz
2003-03-12 18:38         ` Andrew Cagney
2003-03-12 18:48         ` Paul Koning
2003-03-12 19:00           ` Daniel Jacobowitz
2003-03-12 21:04             ` Andrew Cagney
2003-03-12 20:06               ` Daniel Jacobowitz
2003-03-02  6:52 Michael Elizabeth Chastain
2003-03-02  9:35 ` Stephane Carrez
2003-03-03  4:50   ` Daniel Jacobowitz
2003-02-24  2:36 Michael Elizabeth Chastain
2003-03-01 13:35 ` Mark Kettenis
2003-03-01 20:33   ` Joel Brobecker
2003-03-01 22:38     ` Mark Kettenis
2003-03-01 23:41       ` Andrew Cagney
2003-03-02  0:28         ` Daniel Jacobowitz
2003-03-03 11:26           ` Richard Earnshaw
2003-03-03 11:52             ` Keith Walker
2003-03-01 23:39     ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200303012057.h21KvFv26400@duracef.shout.net \
    --to=mec@shout.net \
    --cc=brobecker@gnat.com \
    --cc=gdb@sources.redhat.com \
    --cc=kettenis@chello.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).