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


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.

-- 
Daniel Jacobowitz


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