Re: remote protocol extensions for reading and writing registers

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" <jtc@redbacknetworks.com> wrote (a very long time ago):
 
> I was also thinking of some alternative to obtaining all registers
> when a subset is needed.  I had two contexts in mind: obtaining just
> the control registers when returning from a step or continue, and
> avoiding transferring FP, MMU, MMX, etc. registers when those are 
> not in use or on a processor varient that doesn't include them.  

So GDB's current strategy is to:

	get basic registers from that ``T'' response
		(this could probably be better analyzed, I've
		watched GDB and the registers returned (apart from
		the PC) didn't appear to help that much :-)

	get remaining registers using ``g'' as a single block

GDB's core is only interested in the ABI registers (used by GDB to
analize things like a stack frame).
The typical embedded programmer (and MMX programmer now I guess) is also
interested in other ISA specific registers.  As you note, there needs to
be a way of obtaining them.

The posibilities you've raised include:

	o	target specific register blocks

	o	<bitmask> prefix

	o	register lists (like P/T)

Thinking about it, we've got:


	o	blocks of registers with clear definitions
		obtainable from the ISA.

		FP and MMX registers are hopefully good examples.

		Within an ISA family these generally don't change.

		Perhaphs your block suggestion is best for this
		(WMMX, WFPU, W0, W1, ......?).

		It should be noted that, if nothing else separating
		the floating-point and general-purpose registers would
		be of benefit anyway.

		Um, hmm, this IA-64 thingie has: 128x64bit GPRs,
		128x82 bit FPRs; 8x64bit branch registers; 64x1bit
		predicate registers; 128x64 bit application registers
		(oh and a 64bit PC :-). SCARY!
		(check www.intel.com / somewhere).


	o	ISA specific registers which could even change between
		spins of a piece of silicon....

		Often also these registers are sparse - consider the
		PPC's system registers - all 1024 of them.

		Here we need both a mechanism for reading/writing
		sparce registers (P/p?) and for determining the
		set of registers supported by the target.

One idea I've played with is having GDB query the target for a table of
special register names/numbers.  GDB could then augment the existing
register name lookup table with that list.  The special purpose
registers would be requested individually using (P/p).

Like anything else, this has advantages and disadvantages: it means that
the engineer in the field can augment their remote stub to support their
custom register list; it also means that there is no uniformity when it
comes to those registers (and the stub gains more bloat).

Please, please make comments and further suggestions?

	Andrew



> A stub that implements the 'T' response eliminates some of need for
> this, since it can return whatever "important" registers are needed.
> However, register read/write commands that can write subsets of all
> the registers may be useful.  They may be even more useful when the
> remote protocol is being used with another front end (perhaps a
> monitor-like control panel)
> 
> Some ideas:
>      * Define register "sets" that define a particular registers.  The
>        new register read/write commands would operate on a set in the
>        same way the global read/write operate today.
> 
>        read registers:  R<set-id>
>        reply            XX....X
> 
>        write regs:      W<set-id>=XX....X
>        reply            OK / ENN
> 
>        Possible sets are:
>        0 - all registers
>        1 - integer registers
>        2 - FP registers
>        3 - control registers???
>        4 - MMX/multimedia registers
> 
>        As each set is represented by a number, the commands will be
>        short; but the stub will have to contain a mapping of what
>        registers are in each set and what their offset is.
> 
>      * Use a bitmask that represents what registers will be read or
>        written in the transaction.
> 
>        read registers:  R<bitmask>
>        reply            XX....X
> 
>        write regs:      W<bitmask>=XX....X
>        reply            OK / ENN
> 
>        The width of the bitmask would have to be sufficent to represent
>        all registers on a machine.  This may be excessive on machines
>        with lots of registers.
> 
>      * Use a scheme like the 'T' response to read/write a sequence of
>        registers.
> 
>        read registers:  Rn...;r...;n...;r...;n...;r...
>        reply            XX....X
> 
>        write regs:      Wn...;r...;n...;r...;n...;r...=XX....X
>        or:              Wn...;r...=XX..X;n...;r...=XX..X;n...;r...=XX..X
>        reply            OK / ENN
> 
>        There's not much to recommend this scheme, as it exchanges long
>        responses with long commands.

BTW, W/w is available, R is taken :-)