From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: gdb@sourceware.cygnus.com
Subject: CVS GDB and Register Numbers and Remote Protocol.
Date: Wed, 04 Oct 2000 04:00:00 -0000
Message-id: <39DB0CDB.6523ADE6@ozemail.com.au>
References: <14809.15857.439093.624776@kwikemart.cygnus.com> <200010030955.LAA03533@reisser.regent.e-technik.tu-muenchen.de> <14810.35704.744724.716669@kwikemart.cygnus.com>
X-SW-Source: 2000-10/msg00013.html

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
43undefined 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.

Thoughts Anyone?

Steven Johnson