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
next prev 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