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

[Jim Blandy <jimb at redhat dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Fri, Jul 02, 2004 at 11:39:41AM -0400, Andrew Cagney wrote:
> > >On Thu, Jul 01, 2004 at 01:44:53PM -0500, Jim Blandy wrote:
> > >
> > >>>
> > >>>Daniel Jacobowitz <drow@false.org> writes:
> > >>
> > >>>>> 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?
> > >>
> > >>>
> > >>>No, regsets are perfect for 'g'.  I was thinking of the single-
> > >>>register case (all under the assumption that we'd like to restrict
> > >>>uses of supply_register and collect_register to regset functions).
> > >>>What do you do with, say, the individual registers from your fancy 'T'
> > >>>reply?
> > >
> > >
> > >I have no idea.  Good question.
> > 
> > (I've attached a few of comments that go with TARGET_OBJECT, check the 
> > archives for qPart)
> > 
> > For regsets, the ``void *buffer/long length'' pair can be replaced by a 
> > single ``byte array'' object.
> > 
> > The regset code can then send offset/length xfer requests to that ``byte 
> > array''.  For cores, the byte array would extract the bytes from the 
> > core file; for ptrace, the byte array would extract the bytes using the 
> > relevant ptrace call; and for the remote inferior, the request would be 
> > converted into one or more qPart packets (sending the 
> > regset/offset/length across the wire).
> > 
> > When it comes to a `T' reply, the remote inferior can push 
> > regset/offset/length data for parts of the regset buffer that it thinks 
> > are interesting.
> 
> If I'm interpreting your answer right, it is: "don't do anything about
> it, change the remote protocol instead", right?
> 
> 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.