Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: make sim interface use gdbarch methods for collect/supply
Date: Thu, 01 Jul 2004 17:23:00 -0000	[thread overview]
Message-ID: <vt2n02jabhq.fsf@zenia.home> (raw)
In-Reply-To: <20040701024822.GA5875@nevyn.them.org>


Daniel Jacobowitz <drow@false.org> writes:
> > If you mean the regset stuff: the sim doesn't present its registers in
> > terms of a single structure that one could pass to a
> > supply_regset_ftype or collect_regset_ftype value; you make one call
> > to a sim function to transfer each register.
> 
> The interface may need some surgery to do it, but the sim's registers
> are conceptually a regset, aren't they?  We could collect each register
> >From the sim into a buffer and write a "struct regset" describing that.
> This could happen in an arch-independent way in remote-sim, and then
> the regset be provided by the target architecture.

Grumble.

So you're setting forth as an ideal that remote-sim.c would stop using
supply_register and collect_register altogether, and just use a
regset's supply and collect functions, right?

The regset interface isn't very well-suited for single-register
accesses.  Only the regset's collect and supply functions know which
bytes of the buffer are going to be used to supply a particular raw
register's value.  So when gdbsim_fetch_register is passed a specific
raw register number, it has no way of knowing which bytes of the
buffer to populate from the sim before it invokes the regset's supply
function.  For it to know that, it needs to know the correspondence
between the raw register cache and the cooked form provided by the
target --- but the whole point of introducing regsets in the first
place was to isolate that knowledge in regset supply and collect
functions.  So the sim would need to always read a full sim regset,
even when only one register was requested.

For the sim, that might all be in the noise, and not matter.  But if
you want to push the same sort of change through remote.c, then you
can't use that workaround.  For now, GDB's internal raw regcache
layout must correspond exactly to that of the 'g' packet, but I assume
that's not supposed to hold forever.  So when the remote protocol
registers don't exactly correspond to raw regcache registers, how will
GDB know where to place their contents in the buffer before calling
the supply function?

At the moment, regsets are used only to transfer entire register sets,
so we haven't run into it.


  reply	other threads:[~2004-07-01 17:23 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 [this message]
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
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=vt2n02jabhq.fsf@zenia.home \
    --to=jimb@redhat.com \
    --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