Re: [PATCH] arm64: kgdb: Match pstate size with gdbserver protocol

From: Daniel Thompson
Date: Tue May 10 2016 - 09:42:03 EST


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.