Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jul 15, 2004 at 01:30:22PM -0500, Jim Blandy wrote:
> 
> 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.

Then perhaps that should be changed.  In practice, many
pseudo-registers are suppliable.  It might even be possible to
rearrange the interfaces such that *_pseudo_register_write can be used,
via regcache_cooked_write, i.e. supply cooked registers.

This would require rethinking of the raw/cooked boundary.  Currently
the boundary is that raw registers are those we can query the target
for.  If you have a remote target that can not supply the same
registers we keep in the raw regcache, we have a design problem.

-- 
Daniel Jacobowitz