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

[Andrew Cagney <cagney@gnu.org>]

> 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.