Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alan Hayward <Alan.Hayward@arm.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: nd <nd@arm.com>
Subject: [PATCH 0/7] Regcache: Split out target regcache functionality
Date: Thu, 17 Aug 2017 08:46:00 -0000	[thread overview]
Message-ID: <D453EE50-9381-49C4-8B02-3EA52138D387@arm.com> (raw)

This set of patches splits the existing regcache into a regcache
and a target_regcache subclass.
Doing this will simplify the interactions between a regcache and
the target, and will allow for the writable regcache copies.

A target_regcache is a regcache connected to a target. Reads and
writes of register values are passed through to the target.
A target_regcache cannot be readonly (because this doesn't make
sense).

Meanwhile, a regcache (sometime referred to as a detached regcache)
is not connected to a target. By default it is readonly, but does
not have to be. In addition to the raw registers a regcache also
caches cooked register values. Duplicating a target_regcache will
always result in a detached regcache.

Both regcache and target_regcache support the full set of raw_read,
raw_write, raw_collect, raw_supply, cooked_read, cooked_write
functions and all their variations. A user of a regache does not
need to treat the two types any differently - your regcache just
does the correct thing. For example, on a target_regcache,
raw_write will write to both the cache and the target, but on
a recache it will only write to the cache.

With this set of patches, the regcache for the current thread (as
given by get_current_regcache()), is now a target_regcache, that
will perform exactly the same functionality as the regcache in
the exisiting head.

An earlier plan for this set of patches was that the detached
regcache would not support raw_write, raw_collect, cooked_read,
cooked_write. The problem is many of the target hooks then need
updating to only accept target_regcache. Many of the implementations
of the target hooks then call back into the regcache, causing those
functions in turn to be dependant on the new classes, exploding the
size of the patch. It then become very fiddly/confusing to maintain
which type of regcache is required at any point.

If you want to look at the while series together, I’ve pushed it to:
remotes/origin/users/alahay01/targetregcache

The whole set of patches have been tested on a --enable-targets=all
build with board files unix, native-gdbserver and unittest.exp.


Thanks,
Alan.

             reply	other threads:[~2017-08-17  8:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-17  8:46 Alan Hayward [this message]
2017-08-23 10:03 ` Yao Qi
2017-08-23 12:44   ` Alan Hayward
2017-08-23 10:08 ` Yao Qi

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=D453EE50-9381-49C4-8B02-3EA52138D387@arm.com \
    --to=alan.hayward@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nd@arm.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