On 10/05/16 11:45, Mark Rutland wrote:
When commit 44679a4f142b ("arm64: KGDB: Add step debugging support") was
introduced it was paired with a gdb patch that made an incompatible
change to the gdbserver protocol. This patch was eventually merged into
the gdb sources:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=a4d9ba85ec5597a6a556afe26b712e878374b9dd
The change to the protocol was mostly made to simplify big-endian support
inside the kernel gdb stub.
While that was how we discovered the inconsistency, a major concern is
that SPSR_EL* (i.e. PSTATE), as accessed by MRS/MSR is a 64-bit
quantity, even if the upper 32 bits are RES0 today.
It is conceivable that the upper 32 bits could be used in future (as
happened with CLIDR_EL1), and for this reason we expose those upper 32
bits from the kernel, and treat system registers as 64-bit quantities
generally.
These cases are not exactly the same.
CLIDR_ELx is (or was) architecturally defined as a 64-bit register and
explicitly marks the upper 32-bits as RES0.
That is not the case for SPSR_ELx; this register is architecturally
defined to be 32-bit.
I know that doesn't *prevent* SPSR_ELx from being expanded in the future
it is not unreasonable for gdb to design its wire protocol based on the
description found in the architecture manual.
So this was also about ensuring the interface was consistent and to some
extent future-proof.
gdb remote protocol is already future proof and has never at any point
contradicted the architecture.
However the changes to the protocol in 7.7.x and 7.8.0 were analogous to
an unexpected ABI change rather than a carefully controlled introduction
of a new feature. Like the kernel, once detected, they were reversed ;-) .
Daniel.
