From: Mark Kettenis <kettenis@chello.nl>
To: ac131313@redhat.com
Cc: drow@mvista.com, gdb@sources.redhat.com
Subject: Re: [RFC] Register sets
Date: Thu, 04 Sep 2003 21:31:00 -0000 [thread overview]
Message-ID: <200309042129.h84LTvdt034293@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <3F54E41C.9040304@redhat.com> (message from Andrew Cagney on Tue, 02 Sep 2003 14:40:28 -0400)
Date: Tue, 02 Sep 2003 14:40:28 -0400
From: Andrew Cagney <ac131313@redhat.com>
> The read_regset function is necessary to support the `gcore' command.
> It should use regcache_raw_read to fetch all relevant registers from
> the running target, such that we don't need target_fetch_registers(-1)
> first.
GDB currently has a conflict here. GCORE should definitly use
regcache_raw_read, but that still leaves the ptrace code writing back
register values - it uses regcache_collect. Hmm, perhaphs it two should
be using a regcache_raw_read anyway - might even make it possible to
eliminate "target_prepare_to_store"?
We've said in the past that we the register cache is a write-through
cache. Not all of our targets treat it exactly like that, however,
for the ones that do (and all of them really should), it shouldn't
make a difference whether we use regcache_raw_collect or
regcache_raw_read. If we're storing a single register, that register
must be valid, and therefore won't trigger fetching any registers. If
we're storing all registers, we must have fetched them all before, and
they should all be valid too. That said, we should be able to
eliminate regcache_raw_collect in the future.
Mark
next prev parent reply other threads:[~2003-09-04 21:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-23 22:50 Mark Kettenis
2003-08-24 16:43 ` Daniel Jacobowitz
2003-08-25 22:35 ` Mark Kettenis
2003-08-26 15:49 ` Andrew Cagney
2003-08-26 16:55 ` Daniel Jacobowitz
2003-08-27 3:50 ` Andrew Cagney
2003-08-31 14:04 ` Mark Kettenis
2003-09-02 18:40 ` Andrew Cagney
2003-09-04 21:31 ` Mark Kettenis [this message]
2003-09-04 12:55 ` Daniel Jacobowitz
2003-09-04 14:00 ` Andrew Cagney
2003-09-04 14:08 ` Daniel Jacobowitz
2003-09-04 15:04 ` Andrew Cagney
2003-09-04 15:13 ` Daniel Jacobowitz
2003-09-04 22:07 ` Mark Kettenis
2003-09-04 22:05 ` Mark Kettenis
2003-09-04 22:16 ` Andrew Cagney
2003-09-04 22:59 ` Andrew Cagney
2003-09-05 23:15 ` Daniel Jacobowitz
2003-09-09 4:21 ` Andrew Cagney
2003-09-04 21:58 ` Mark Kettenis
2003-09-06 0:02 ` Jim Blandy
2003-09-06 14:18 ` Mark Kettenis
2003-09-09 4:51 ` Andrew Cagney
2003-09-09 17:15 ` Jim Blandy
2003-09-09 19:16 ` Andrew Cagney
2003-08-29 20:20 ` Mark Kettenis
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=200309042129.h84LTvdt034293@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=ac131313@redhat.com \
--cc=drow@mvista.com \
--cc=gdb@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