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

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

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.

-- 
Thiago
(he/him)