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

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote:
> 
> 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.

Don't do that then.  Pass those as a regset, not numbered in the T
packet.  Or have the register renumbering function map that number to
the combined pseudo register!

-- 
Daniel Jacobowitz