Re: G packet format ...

[Andrew Cagney <ac131313@cygnus.com>]

>> >I guess I posted my gdbserver register cache patch before I converted
>> >it to generate them from a shell script.  Here's what I've been using. 
>> >I didn't consider the issue of only-transferable-in-P-packet registers
>> >(and I still don't see a good reason... well, maybe I can come up with
>> >one, actually.  Things that react when read.).

[...]

> I'm a little skeptical of using the P packet for registers
> not-present-in-all-cases, either.  Perhaps in the morning I'll be able
> to figure out why.

Not sure it is relevant, however, the following feature of the remote 
protocol is interesting.

The G packet contains all registers.  There for, if the G packet is 
short, GDB assumes that any missing registers are zero.

Consider the sequence:

Target stops.  Supplies value for register 1000 in T packet.

User does something to cause register ``0'' to be fetched and this is 
done via a G packet.

Two things can happen:

	o	target supplies GDB with all registers (0..1000)
		which makes for a very large G packet.

	o	target supplies GDB with a subset of registers
		(a short packet) and GDB interprets that to mean
		that register 1000 should be set to zero.

Ulgh.


By allowing registers beyond the end of a G packet. These problems are 
avoided.

A variation on my change might be to allow the target to bundle up more 
than the official NR of registers in a G packet.  However, not having 
them does not mean that they are zero.

enjoy,
Andrew