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

[Daniel Jacobowitz <drow@false.org>]

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

OK, that's a legitimate reason not to use regsets for this.  A reason
was all I wanted :) I still think it might be advantageous to always
fetch all registers for the sim case, though, and use regsets anyway.
We already do this for many native targets (PTRACE_GETREGS) because
that's lowest latency.

> 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.

GDB won't have to know where to place their contents in the buffer!
That's the point of using a regset.  You convert the 'g' packet output
to a binary blob in the obvious way, and then that's your regset.  The
target architecture supplies a regset that expects the format provided
by the 'g' packet.  Is there some problem with that plan?

-- 
Daniel Jacobowitz