Re: [PATCH v2 1/7] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE

[Marc Zyngier <maz@kernel.org>]

On Wed, 01 Jul 2026 06:16:21 +0100,
Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:
> 
> Hello Srinath,
> 
> Srinath Parvathaneni <Srinath.Parvathaneni@arm.com> writes:
> 
> >>> *  info registers por_el0
> >>> *  p $por_el0
> >>> *  p/x $por_el0
> >>> *  set $por_el0 = <value>
> >>
> >>One question, more about general policy on the AArch64 GDB port:
> >>
> >>Should the register name have the _el0 suffix? It's more than half of
> >>the register name (though tab completion helps).
> >>
> >>We don't currently have that suffix in the name of any register. And in
> >>the case of Guarded Control Stack, I didn't add it. For native
> >>debugging, it will always be the register at EL0. For remote debugging,
> >>I assumed the target would send the register corresponding to the
> >>current exception level in the inferior.
> >>
> >>Can there be a situation where it would be possible to see both the EL0
> >>and EL1 (for example) registers at the same time? Or a situation where
> >>the inferior is at EL1 but one wants to see the register at EL0, or
> >>vice-versa?
> >>
> >
> > Thanks Thiago for the review. I'll address the other review comments and
> > post a new version of the patches.
> >
> > I'm happy to follow the existing AArch64 GDB convention and expose the register
> > as `POR` for consistency.
> >
> > That said, after discussing this with kernel/KVM developers, there are valid
> > debugging scenarios (e.g. KGDB or guest debugging via KVM/QEMU) where exposing
> > `POR_EL0`, `POR_EL1`, and `POR_EL2` simultaneously would be useful.
> 
> Thanks for checking! Considering it's indeed useful then it's better to
> use $por_el0 in this patch series as you have done.
> 
> > This seems like a broader GDB register naming issue rather than
> > something specific to FEAT_S1POE.
> 
> I agree. This just seemed like a good moment to consider this question.

It would certainly make our life easier if GDB was in general adopting
the architecture nomenclature.

It is probably fine to have a "shorthand" such as POR for POR_EL0, but
I'd like to make sure that it is possible to unambiguously target the
correct register for the cases where we have to debug a full guest
(which is something people actively do using the QEMU GDB stubs).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.