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 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.
As far as I can tell, regsets don't serve this case well, which makes
them (in their current state) less than suitable as a universal
register transfer interface.
Andrew
/* Request the transfer of up to LEN 8-bit bytes of the target's
OBJECT. The OFFSET, for a seekable object, specifies the starting
point. The ANNEX can be used to provide additional data-specific
information to the target.
Return the number of bytes actually transfered, zero when no
further transfer is possible, and -1 when the transfer is not
supported.
NOTE: cagney/2003-10-17: The current interface does not support a
"retry" mechanism. Instead it assumes that at least one byte will
be transfered on each call.
NOTE: cagney/2003-10-17: The current interface can lead to
fragmented transfers. Lower target levels should not implement
hacks, such as enlarging the transfer, in an attempt to compensate
for this. Instead, the target stack should be extended so that it
implements supply/collect methods and a look-aside object cache.
With that available, the lowest target can safely and freely "push"
data up the stack.