On 8/8/25 9:14 AM, Peter Maydell wrote:
On Fri, 8 Aug 2025 at 17:11, Pierrick Bouvier
<pierrick.bouv...@linaro.org> wrote:
On 8/8/25 5:26 AM, Manos Pitsidianakis wrote:
On Fri, Aug 8, 2025 at 3:21 PM Peter Maydell <peter.mayd...@linaro.org> wrote:
On Fri, 8 Aug 2025 at 12:30, Manos Pitsidianakis
<manos.pitsidiana...@linaro.org> wrote:
The debugger already has this information in the 'cpsr'
register, so it could implement convenience views of
the subfields itself if it liked.
Yep, but consider: it is a register, architecturally, so it's nice to
include it for consistency. It's redundant only because gdb has cpsr
which is not a register. So this is about more about being technically
correct than correcting an actual problem.
I agree with Manos on this.
As mentioned on a previous thread, cpsr is not even supposed to exist
for aarch64. So adding architecturally defined registers, even if data
is redundant with cpsr, should not be a problem.
I'm sure gdb folks can understand this too.
I'm not saying this is the wrong way to represent this.
I'm just saying we're not the only gdbstub in the world,
and it would be nice to have a wider discussion than just
QEMU folks so we are consistent about how we represent
PSTATE (including what we want to do about the new
bits that appear in the high 32 bits of an SPSR), before
we commit to any particular direction.
Considering we have our own set of gdb xml, is that really important to
agree on pstate layout before we simply make those registers visible on
our side?
The new registers added in this series on gdb/kgdb side at the moment,
so we don't really break anything.
I agree it would be good to see this on gdb side, but my point is that
we are not necessarily stuck and we can make this visible without
waiting two releases. As well, it would be a good motivation to add this
on gdb showing QEMU already exposes this.
-- PMM
