This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]