Broken 'g' or 'P' Packet in Remote Protocol (from CVS).

[Steven Johnson <sbjohnson at ozemail dot com dot au>]

I am using a very recent version of GDB from CVS (only a couple of days old).

I Have a strange thing happening with register numbers and my remote target (A
Motorola PowerPC MPC860 board). The problem is that the offsets needed for the
response to the 'g' request to read all registers are not the same as those
sent in the 'P' packet to change them. This is really bad and confusing. It
makes the stub a mess trying to cope with it. What I have traced it to is:

The response to 'g' needs to have the registers reported in the same order as
info all-registers. No Problem.

But the 'P' packet sends the register number as the offset of the register in
the table registers_860. This Normally would be fine, but there are lots of
spurious registers in this table for the mpc860, and some of them do not show
in the info all-registers display. The Prime culprits being PPC_UISA_SPRS where
there is a reg placeholder R0 at the end of the entry which is a non existent
register and is never shown. (This offsets all following registers by 1) and
then there is PPC_OEA_SPRS with R64(asr) which is not present on 32 bit
architectures. which again offsets all following registers by 1. So if you were
to look at info registers you would see that $der is register number 125, but
the 'P' packet writes to register number 127 which is $countb (according to
info all-registers).

If i put these extra un-defined registers in the 'g' response then
info-registers no longer shows the correct information, shifiting all data down
by 1 after each of these. (But the 'P' packet now has the right numbers).

What do I do. This seems very messy. Further, the way the registers are defined
for the MPC860, there are 75 unimplemented registers defined in the
registers_860 structure (32 floating point registers and 43 undefined SPR's).
Thats 44% of unuseful crap declared.

Would anyone have any objections to me culling the 74 useless definitions from
this structure. This would be the most immediate fix, Im not sure what should
be correct behaviour for a stub thugh. What is being handled incorrectly by
GDB, 'g' or 'P'? I have no problems effecting a fix, but there are 2 ways it
could be achieved.

I Tend to think that 'P' is the broken thing..

Thoughts Anyone?

Steven Johnson