On Fri, Aug 1, 2025 at 4:33 PM Peter Maydell <peter.mayd...@linaro.org> 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.) > > 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? >
IIUC, this is only a problem if you use the default gdb architecture register map, but QEMU ships its own as part of gdbstub, so it's free to change register definition of cspr. Or add a new PSTATE register. > (I'll see if I can find out if anybody's already looked at this > for the native debug case.) > > thanks > -- PMM >
