RFA: make sim interface use gdbarch methods for collect/supply
Daniel Jacobowitz
drow@false.org
Thu Jul 1 17:31:00 GMT 2004
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
More information about the Gdb-patches
mailing list