Re: remote protocol extensions for reading and writing registers

[jtc@redback.com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> So GDB's current strategy is to:
Andrew>
Andrew> 	get basic registers from that ``T'' response
Andrew> 	(this could probably be better analyzed, I've
Andrew> 	watched GDB and the registers returned (apart
Andrew> 	from the PC) didn't appear to help that much
Andrew> 	:-)

Hmmm.  When I implemented the `T' response this for our x86 stub, I
set remotedebug and watched the protocol as I stepped through code.
GDB always requested all registers immediately after taking control
until I added the PC, SP, and BP.  I suspect the optimal set of
registers to return in a `T' response depends on the processor.

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

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

Andrew> The posibilities you've raised include:
Andrew> o target specific register blocks
Andrew> o <bitmask> prefix
Andrew> o register lists (like P/T)

Yes.  And using any of the above methods of specifying registers could
get real ugly on real world processors.

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

Andrew> 		FP and MMX registers are hopefully good
Andrew> 		examples.

Andrew> 		Within an ISA family these generally don't
Andrew> 		change.

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

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

Indeed.  I've noticed that some of the sample stubs only nominally
support floating point.  Floating point values are not saved nor
restored --- the memory in the register block reserved for FP regs is
simply zeroed before the block is returned in the register fetch
command and is simply ignored in the register set command.  As a
result, we have all the overhead of supporting FP registers, but
none of the benefits.

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

The IA-64 is an extreme example, but we have a problem where the
protocol MTU (ie. PBUFSIZ) is defined in terms of the size of the
memory required to save all registers.  The most significant
implications of this is with datagram transports.  If PBUFSIZ is
smaller that the physical MTU, the only drawback is deminished
performance of bulk memory transfers.  But if PBUFSIZ is smaller, 
you lose...  (At the very least, this requires the user to layer 
on another protocol to fragment and reassemble remote protocol 
packets).

This seems to indicate that there should be some mechanism in the
protocol such that GDB and the stub identify to each other the maximum
MTU that can be used; And that any register transfer command have the
ability to split the command (or the results) over multiple packets.

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

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

I think it's important to keep them sparse as well.  For example, if
you "renumbered" the existing model specific registers to be
consecutive, you'd lose as soon as a new one was added.

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

Perhaps P/p could be extended to fetch/set more than one register at a
time similar to the `T' response.  At least for setting registers, GDB
could have a `register cache' and only write regs just before program
execution is resumed (perhaps this wouldn't work with MSRs though, in
those cases, you might want the side effect of setting those registers
to take effect immediately).

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

Do you have any idea about how these queries would be implemented?

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

Andrew> Please, please make comments and further suggestions?

	--jtc

-- 
J.T. Conklin
RedBack Networks