Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Overhaul regcache for {save,restore}_reggroup
Date: Wed, 13 Nov 2002 09:00:00 -0000	[thread overview]
Message-ID: <3DD28521.30607@redhat.com> (raw)
In-Reply-To: <3DCACF5A.6010801@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

> Hello,
> 
> This patch brings in the last big change sitting on the reggroups branch.
> 
> It adds regcache save/restore functions to to the regcache.
> These functions save/restore a subset of registers determined by the save/restore reggroups (by default REGNUMs in the range [0 .. NUM_REGS) are in both the save_reggroup and restore_reggroup, and hence are saved/restored).
> 
> As part of this, a saved read-only regcache is expanded so that it can hold the saved value of any register in the full [0 .. NUM_REGS+NUM_PSEUDO_REGS) range.  This is so that architectures with memory-mapped registers (which fall into the range [NUM_REGS .. NUM_REGS+NUM_PSEUDO_REGS) have somewhere to save them.
> 
> I'll look to commit it in a few days,
> 
> (Oh, and it deletes the last remaining core reference to read_register_bytes() or write_register_bytes()).

Attached is the next in the series.  It modifies the regcache create 
code so that it is clearly computing the dimensions of a cooked register 
cache and then using that as the size of the raw register cache.

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 7111 bytes --]

2002-11-13  Andrew Cagney  <cagney@redhat.com>

	* regcache.c (struct regcache_descr): Add fields
	sizeof_cooked_registers and sizeof_cooked_register_valid_p.
	(init_legacy_regcache_descr): Compute the size of a cooked
	register cache and then assign that to sizeof_raw_registers.  Set
	sizeof_raw_register_valid_p to sizeof_cooked_register_valid_p
	(init_legacy_regcache_descr): Ditto.

Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.64
diff -u -r1.64 regcache.c
--- regcache.c	13 Nov 2002 16:07:03 -0000	1.64
+++ regcache.c	13 Nov 2002 16:48:10 -0000
@@ -66,6 +66,8 @@
      both raw registers and memory by the architecture methods
      gdbarch_register_read and gdbarch_register_write.  */
   int nr_cooked_registers;
+  long sizeof_cooked_registers;
+  long sizeof_cooked_register_valid_p;
 
   /* Offset and size (in 8 bit bytes), of reach register in the
      register cache.  All registers (including those in the range
@@ -93,20 +95,28 @@
   gdb_assert (gdbarch != NULL);
 
   /* FIXME: cagney/2002-05-11: Shouldn't be including pseudo-registers
-     in the register buffer.  Unfortunatly some architectures do.  */
+     in the register cache.  Unfortunatly some architectures still
+     rely on this and the pseudo_register_write() method.  */
   descr->nr_raw_registers = descr->nr_cooked_registers;
-  descr->sizeof_raw_register_valid_p = descr->nr_cooked_registers;
+  descr->sizeof_raw_register_valid_p = descr->sizeof_cooked_register_valid_p;
 
-  /* FIXME: cagney/2002-05-11: Instead of using REGISTER_BYTE() this
-     code should compute the offets et.al. at runtime.  This currently
-     isn't possible because some targets overlap register locations -
-     see the mess in read_register_bytes() and write_register_bytes()
-     registers.  */
+  /* Compute the offset of each register.  Legacy architectures define
+     REGISTER_BYTE() so use that.  */
+  /* FIXME: cagney/2002-11-07: Instead of using REGISTER_BYTE() this
+     code should, as is done in init_regcache_descr(), compute the
+     offets at runtime.  This currently isn't possible as some ISAs
+     define overlapping register regions - see the mess in
+     read_register_bytes() and write_register_bytes() registers.  */
   descr->sizeof_register = XCALLOC (descr->nr_cooked_registers, long);
   descr->register_offset = XCALLOC (descr->nr_cooked_registers, long);
   descr->max_register_size = 0;
   for (i = 0; i < descr->nr_cooked_registers; i++)
     {
+      /* FIXME: cagney/2001-12-04: This code shouldn't need to use
+         REGISTER_BYTE().  Unfortunatly, legacy code likes to lay the
+         buffer out so that certain registers just happen to overlap.
+         Ulgh!  New targets use gdbarch's register read/write and
+         entirely avoid this uglyness.  */
       descr->register_offset[i] = REGISTER_BYTE (i);
       descr->sizeof_register[i] = REGISTER_RAW_SIZE (i);
       if (descr->max_register_size < REGISTER_RAW_SIZE (i))
@@ -115,8 +125,13 @@
 	descr->max_register_size = REGISTER_VIRTUAL_SIZE (i);
     }
 
-  /* Come up with the real size of the registers buffer.  */
-  descr->sizeof_raw_registers = REGISTER_BYTES; /* OK use.  */
+  /* Compute the real size of the register buffer.  Start out by
+     trusting REGISTER_BYTES, but then adjust it upwards should that
+     be found to not be sufficient.  */
+  /* FIXME: cagney/2002-11-05: Instead of using REGISTER_BYTES, this
+     code should, as is done in init_regcache_descr(), compute the
+     total number of register bytes using the accumulated offsets.  */
+  descr->sizeof_cooked_registers = REGISTER_BYTES; /* OK use.  */
   for (i = 0; i < descr->nr_cooked_registers; i++)
     {
       long regend;
@@ -125,15 +140,14 @@
          legacy code is free to put registers in random places in the
          buffer separated by holes.  Once REGISTER_BYTE() is killed
          this can be greatly simplified.  */
-      /* FIXME: cagney/2001-12-04: This code shouldn't need to use
-         REGISTER_BYTE().  Unfortunatly, legacy code likes to lay the
-         buffer out so that certain registers just happen to overlap.
-         Ulgh!  New targets use gdbarch's register read/write and
-         entirely avoid this uglyness.  */
       regend = descr->register_offset[i] + descr->sizeof_register[i];
-      if (descr->sizeof_raw_registers < regend)
-	descr->sizeof_raw_registers = regend;
+      if (descr->sizeof_cooked_registers < regend)
+	descr->sizeof_cooked_registers = regend;
     }
+  /* FIXME: cagney/2002-05-11: Shouldn't be including pseudo-registers
+     in the register cache.  Unfortunatly some architectures still
+     rely on this and the pseudo_register_write() method.  */
+  descr->sizeof_raw_registers = descr->sizeof_cooked_registers;
 }
 
 static void *
@@ -151,6 +165,7 @@
      directly onto the raw register cache while the pseudo's are
      either mapped onto raw-registers or memory.  */
   descr->nr_cooked_registers = NUM_REGS + NUM_PSEUDO_REGS;
+  descr->sizeof_cooked_register_valid_p = NUM_REGS + NUM_PSEUDO_REGS;
 
   /* Fill in a table of register types.  */
   descr->register_type = XCALLOC (descr->nr_cooked_registers,
@@ -178,12 +193,9 @@
      array.  This pretects GDB from erant code that accesses elements
      of the global register_valid_p[] array in the range [NUM_REGS
      .. NUM_REGS + NUM_PSEUDO_REGS).  */
-  descr->sizeof_raw_register_valid_p = NUM_REGS + NUM_PSEUDO_REGS;
+  descr->sizeof_raw_register_valid_p = descr->sizeof_cooked_register_valid_p;
 
-  /* Lay out the register cache.  The pseud-registers are included in
-     the layout even though their value isn't stored in the register
-     cache.  Some code, via read_register_bytes() access a register
-     using an offset/length rather than a register number.
+  /* Lay out the register cache.
 
      NOTE: cagney/2002-05-22: Only register_type() is used when
      constructing the register cache.  It is assumed that the
@@ -204,14 +216,15 @@
 	  descr->max_register_size = descr->sizeof_register[i];
       }
     /* Set the real size of the register cache buffer.  */
-    /* FIXME: cagney/2002-05-22: Should only need to allocate space
-       for the raw registers.  Unfortunatly some code still accesses
-       the register array directly using the global registers[].
-       Until that code has been purged, play safe and over allocating
-       the register buffer.  Ulgh!  */
-    descr->sizeof_raw_registers = offset;
-    /* = descr->register_offset[descr->nr_raw_registers]; */
+    descr->sizeof_cooked_registers = offset;
   }
+
+  /* FIXME: cagney/2002-05-22: Should only need to allocate space for
+     the raw registers.  Unfortunatly some code still accesses the
+     register array directly using the global registers[].  Until that
+     code has been purged, play safe and over allocating the register
+     buffer.  Ulgh!  */
+  descr->sizeof_raw_registers = descr->sizeof_cooked_registers;
 
 #if 0
   /* Sanity check.  Confirm that the assumptions about gdbarch are

  parent reply	other threads:[~2002-11-13 17:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-07 12:38 Andrew Cagney
2002-11-13  8:09 ` Andrew Cagney
2002-11-13  9:00 ` Andrew Cagney [this message]
2002-11-13 10:01 ` 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=3DD28521.30607@redhat.com \
    --to=ac131313@redhat.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