Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: addresses and pointers may be different sizes while printing
Date: Thu, 28 Jun 2001 15:35:00 -0000	[thread overview]
Message-ID: <20010628223546.BDE7F5E9CB@zwingli.cygnus.com> (raw)

This is a preparatory patch for removing the D10V dependencies that
have crept into the core of GDB (for example: value_at in valops.c).

The D10V uses 16-bit pointers to index 256k code space.  Since all
D10V instructions are 32 bits long, and naturally aligned, the PC is
really 18 bits long, and the bottom two bits are always zero.  Within
GDB, we model this by using 32-bit *addresses*, and converting
*pointers* (which are 16 bits long) to *addresses* at the appropriate
points.

Without this conversion (which is necessary for some other
architectures as well), the alternative is for GDB to think that
pointers are 32 bits long, while the program being debugged thinks
they're 16 bits long.  As you'd expect, chaos results.

In any case, print_scalar_formatted assumes that pointers and the
addresses they represent are the same length.  This isn't true for the
D10V, so we need to remove that assumption.  That's what this patch is
supposed to do.

There are probably similar problems elsewhere, but we can fix them as
we find them.  I found this one, so I'm fixing it.

2001-06-28  Jim Blandy  <jimb@redhat.com>

	* printcmd.c (print_scalar_formatted): If we are printing an
	address, remember that TARGET_ADDR_BIT is not always equal to
	TARGET_PTR_BIT.

Index: gdb/printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.21
diff -c -r1.21 printcmd.c
*** gdb/printcmd.c	2001/06/11 16:05:24	1.21
--- gdb/printcmd.c	2001/06/28 22:25:00
***************
*** 390,395 ****
--- 390,401 ----
    else if (format != 'f')
      val_long = unpack_long (type, valaddr);
  
+   /* If the value is a pointer, and pointers and addresses are not the
+      same, then at this point, the value's length is TARGET_ADDR_BIT, not
+      TYPE_LENGTH (type).  */
+   if (TYPE_CODE (type) == TYPE_CODE_PTR)
+     len = TARGET_ADDR_BIT;
+ 
    /* If we are printing it as unsigned, truncate it in case it is actually
       a negative signed value (e.g. "print/u (short)-1" should print 65535
       (if shorts are 16 bits) instead of 4294967295).  */
 


             reply	other threads:[~2001-06-28 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-28 15:35 Jim Blandy [this message]
     [not found] ` <3B43F682.1040502@cygnus.com>
2001-07-05 10:13   ` Jim Blandy
2001-07-05 13:22     ` Andrew Cagney
2001-07-05 16:33       ` Jim Blandy
2001-07-05 23:14     ` Andrew Cagney
2001-07-06 14:51       ` Jim Blandy
2001-07-10 13:32         ` Andrew Cagney
2001-07-09 19:49 David Taylor

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=20010628223546.BDE7F5E9CB@zwingli.cygnus.com \
    --to=jimb@zwingli.cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    /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