Re: Remote protocol extension for register ranges

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
>> If a target has so many registers that you don't want to read them all
>> with the "g" command packet, I believe you are going to need something
>> similar for the "G" command packet.  Otherwise, any read/modify/write
>> operations GDB does will end up reading and writing the entire set.

Fernando> I agree.  But as you say below, the G packet is a little
Fernando> more complex and we have the P packet already.  I was
Fernando> planning on using P for writes.

How are you planning on changing remote.c to issue your new fetch
multiple registers command?  The target interface for fetching and
storing registers only supports fetch/storing one or all registers?
There's a deferred store mechanism in the sparc port, but I can not
see anything that fetches a subset of registers.

I'm concerned that if you have a fetch multiple registers command
without a corresponding store multiple registers command, you might
see situations where after reading and modifying a set of registers,
GDB may have to issue many, many P commands.  As a result, fetching
and storing all registers could yeild better overall performance due
to command latency.  I saw this doing inferior function calls with
powerpc-eabi-gdb when I added support for P command packet to our
debug stub.

>> For these reasons, I recommend implementing a new set of commands
>> which would deprecate G/g/P/p.
>> 
>> Perhaps something like:
>> 
>> Get Registers:
>> y<start>,<end>
>> 
>> Set Registers:
>> Y<start>,<end>,<register-contents>
>> 

Fernando> This may be a nice option, and I would not discard it for
Fernando> the future (although I am not sure how I would use it from
Fernando> gdb without mixing some different levels of information).

Fernando> I am just planning on making a very small change to gdb and
Fernando> one of the stubs so the registers can be shown.  I don't
Fernando> think I will be given much time to do that so I have to keep
Fernando> it very simple.  That is why I would still rather do the 'g'
Fernando> extension (for now) to be able to work with register numbers
Fernando> (while an eventual "yY" would work with byte offsets).

Whether register numbers vs. byte offsets and lengths are used is not
that important.  Although my protocol description used offsets, after
thinking about it a while I think I prefer register numbers.  Numbers
are already used in the P command packet, and they avoid any issues
with ranges that contain only parts of registers.

I would think that using new command packets would be the fastest way
to accomplish what you want.  You won't have to autonegotiate whether
a debug stub's 'g' command supports a register range.  

Regardless of whether this is implemented as a new command or as a
extension of the 'g' command, I believe it should always specify a
register range.  If you need to fetch a single register, send a range
where that register is both the start and end point; or implement the
'p' command --- fetch single register.

IMO whether you have a day or a year to implement this change has no
bearing on whether a change to the remote protocol should be made.
Every protocol change has a permanence that goes far beyond today's
deadlines.  Far too many changes have been made to the protocol
without full consideration.

        --jtc

-- 
J.T. Conklin
RedBack Networks