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.) 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? (I'll see if I can find out if anybody's already looked at this for the native debug case.) thanks -- PMM
