Re: Remote protocol extension for register ranges

[Andrew Cagney <ac131313 at cygnus dot com>]

Fernando Nasser wrote:
> 
> Presently, the remote protocol can only read all registers of a target.
> This is OK for the context registers (the ones that are saved by the OD
> on a context switch) but this is a serious limitation for machines that
> have lots of additional registers.  It is just not feasible to read them
> all at every "g" packet.
> 
> I would like to add parameters to the "g" packet.  Something similar has
> been proposed before -- the only difference is that I would like the
> parameters to be a register number or a register number range range.
> 
> For instance:
> 
> g82      Reads register 82
> g31-40   Reads registers 31-40
> 
> Gdb would test for the acceptance of these types of packets by the stub
> and fall back to the less efficient form if not (like it does for "P"
> packets).
> 
> I really need this feature as do other people that are dealing with one
> of the numerous microprocessors that have too many extra registers.  And
> it is becoming quite urgent now.
> 
> What is the current thinking about this?  Are there other proposals I am
> not aware of?  What are the maintainers position?

FYI, I had two potential ideas in mind.  Which I prefer depends on the
target I'm hacking on.

1.	gG like mM

	Treat the target register file like
	a separate section of memory.

	Without arguments, gG would transfer
	the first few registers.

	With arguments (offset, length) a
	sub section of the register file
	could be transfered.

	If read section was supported, write
	section had to also be supported.

	The first obvious optomization
	would be to read a packet of registers
	when ever a single register was
	requested.

	The problem is that the data
	is very raw.  Embedded hardware
	stores registers in target byte-ordered
	register files.  Remote simulators
	and ICEs like to handle host
	ordered structures.  That raw target
	offset would have to be maped onto
	a sequence of host array elements.


2.	like pP

	The second option would be to
	extend/fix the pP packets (or
	a successor) so that they could
	take a range of registers
	and would use *NETWORK* byte
	ordering.

	Such a system would be good
	for small register transfers
	It could certainly be taught
	to pull in a range of registers
	when only one is asked for.
	The target could even be
	given that freedom: Register
	six please; Certainly, along
	with registers 0..5, 7..9.

	It would be more natural to
	simulators, ICEs and the like
	where the raw data tends to
	come in host structured chunks.

	I guess I could also live with
	pP just being extended.

	Be wary of ``-''.  In some
	situtations the stub can parse it
	as a negative number.


Refering to follow-on threads^D^D^D^D postings:

I note the gG proposal above is like J.T.s ``Y'' proposal - perhaphs
J.T.s posted his suggestion before and I've just picked it up :-/ 
W.R.T. detecting support in the ``gG'' packet, provided the fetch works,
the send would have to work.

The idea to include the ``context'' (J.T.s word) in the request is
interesting.  At present, switching ``contexts'' implicitly switches
both the address space and the register file.  We'd need to figure out
if all commands should take that.  J.T. Have you ever thought of a cpu
as a context?  Considered the possibility of different contexts having
different architectures?

When it comes to:
        It might be convienent to have separate (but potentially
        overlapping) register files for integer registers, floating
        point registers, system registers, miscellaneous registers,
        etc.
I think the register file should contain the raw minimum (no
overlapping).  GDB has to get its act to gether and better handle
overlapping registers.
	
What would I suggest?  Both of course .... :-)  They are solving
different problems.

	Andrew