This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
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