On Fri, 1 Aug 2025 at 17:26, Pierrick Bouvier <pierrick.bouv...@linaro.org> wrote: > > 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?
I think for backwards-compatibility reasons we should stick with the current cpsr format for the information that is in it. We do at least define the fields so you get a nice view of it: (gdb) print $cpsr $4 = [ EL=0 BTYPE=0 Z ] > > 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? kgdb currently does the same thing we do, and exposes a 32-bit "cpsr" value. -- PMM
