On 8/1/25 6:22 AM, Peter Maydell wrote:
On Thu, 31 Jul 2025 at 21:34, Pierrick Bouvier
<pierrick.bouv...@linaro.org> wrote:
On 7/27/25 1:02 AM, Richard Henderson wrote:
diff --git a/target/arm/gdbstub64.c b/target/arm/gdbstub64.c
index 64ee9b3b56..3cef47281a 100644
--- a/target/arm/gdbstub64.c
+++ b/target/arm/gdbstub64.c
@@ -47,6 +47,7 @@ int aarch64_cpu_gdb_read_register(CPUState *cs, GByteArray
*mem_buf, int n)
case 32:
return gdb_get_reg64(mem_buf, env->pc);
case 33:
+ /* pstate is now a 64-bit value; can we simply adjust the xml? */
return gdb_get_reg32(mem_buf, pstate_read(env));
}
If I'm correct, we currently don't expose PSTATE through gdbstub, but
only CPSR. This was a bit confusing for me, considering that CPSR is not
even supposed to exist in Aarch64.
Maybe it's a good opportunity to expose PSTATE instead, which could have
a 64 bits size. This way, we don't break any workflow.
Architecturally, PSTATE is simply an abstract bundling together of
different information: it is not a particular format of a value,
whether 32 or 64 bit or otherwise. (This makes it different to
AArch32 CPSR, which really is a guest-visible register.)
I see.
Then maybe what we really miss are the special registers associated to
PSTATE (CurrentEL, DAIF, NZCV, ...) which are defined architecturally.
When I tried to read EL for the first time using gdbstub, I was looking
for CurrentEL, and finally found it accidently under CPSR.
Would that make more sense?
The thing that *is* defined architecturally is the SPSR_ELx format, which
is where various bits of PSTATE get saved when reporting an exception up
to a higher exception level (and which is pretty much the AArch32 CPSR
format when the lower EL is AArch32). (Note that not *all* of PSTATE
appears in the SPSR_ELx: for example the SME SM and ZA bits are
considered part of PSTATE but they aren't saved into SPSR_ELx.)
For convenience, various pieces of software pass around information
in that SPSR_ELx format. Calling this either "CPSR" or "PSTATE"
is not really correct, but either is perhaps less confusing than
calling it SPSR when the context is that of the code running at the
lower EL rather than the higher.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/include/asm/kgdb.h#n41
suggests that expanding the existing pstate to 64 bits is probably
likely to produce problems. Perhaps we should define a pstate_high
or something for the top 32 bits?
It seems we don't expose pstate at all now, and from your answer above,
it would not make sense to expose it directly, as it's not formally
defined. What is exposed by kgdb?
(I'll see if I can find out if anybody's already looked at this
for the native debug case.)
thanks
-- PMM
