From: Jim Blandy <jimb@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: RFA: make sim interface use gdbarch methods for collect/supply
Date: Thu, 15 Jul 2004 18:35:00 -0000 [thread overview]
Message-ID: <vt2acy15dj5.fsf@zenia.home> (raw)
In-Reply-To: <20040706171646.GA595@nevyn.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote:
> > Daniel Jacobowitz <drow@false.org> writes:
> > > A more practical approach would probably be to maintain a mapping of
> > > the remote protocol register numbers to GDB's internal register numbers
> > > in addition to register sets. I don't see any problem with that.
> >
> > What if the remote protocol wants to talk about a 64-bit register, but
> > GDB's raw regcache sees that as two 32-bit registers? A simple
> > number-to-number mapping doesn't do the trick.
>
> Don't do that then. Pass those as a regset, not numbered in the T
> packet.
You're saying that, since we include register values in the T packet
just for expedience, we can always decline to do that when it's hard,
right? But whether it's hard or not depends on GDB's raw regcache
layout, which isn't supposed to be a matter of public interface. When
someone needs to rearrange the raw regcache, the set of registers
which can be profitably provided in a T packet changes. That's not
the way it should be.
> Or have the register renumbering function map that number to the
> combined pseudo register!
But what would GDB's code handling that packet do with that pseudo-
register number? It can't pass it to a regset or per-register
"supply" function.
next prev parent reply other threads:[~2004-07-15 18:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-30 15:48 Jim Blandy
2004-06-30 15:53 ` Daniel Jacobowitz
2004-06-30 17:00 ` Jim Blandy
2004-07-01 2:48 ` Daniel Jacobowitz
2004-07-01 17:23 ` Jim Blandy
2004-07-01 17:31 ` Daniel Jacobowitz
2004-07-01 18:45 ` Jim Blandy
2004-07-01 18:48 ` Daniel Jacobowitz
2004-07-02 15:39 ` Andrew Cagney
2004-07-06 15:38 ` Daniel Jacobowitz
2004-07-06 17:10 ` Jim Blandy
2004-07-06 17:17 ` Daniel Jacobowitz
2004-07-15 18:35 ` Jim Blandy [this message]
2004-07-16 15:01 ` Daniel Jacobowitz
2004-07-06 17:43 ` Andrew Cagney
2004-07-06 18:31 ` Daniel Jacobowitz
2004-07-02 15:19 ` Andrew Cagney
2004-07-02 22:13 ` Jim Blandy
2004-07-06 15:18 ` 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=vt2acy15dj5.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=cagney@gnu.org \
--cc=drow@false.org \
--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