This is the mail archive of the
mailing list for the GDB project.
Re: G packet format ...
>> >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.
By allowing registers beyond the end of a G packet. These problems are
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.