Re: [PATCH v3 1/5] [PATCH 1/5] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE

[Luis <luis.machado.foss@gmail.com>]

Hi,

On 25/07/2026 07:13, Thiago Jung Bauermann wrote:
> Srinath Parvathaneni <Srinath.Parvathaneni@arm.com> writes:
> 
>>>> *  p/x $por_el0
>>>> *  set $por_el0 = <value>
>>>>
>>>> Example:
>>>> (gdb) info register por_el0
>>>> por_el0 0x7 [ P15=--- P14=--- P13=--- P12=--- P11=--- P10=--- P9=--- P8=--- P7=---
>> P6=--- P5=--- P4=--- P3=--- P2=--- P1=--- P0=rwx ]
>>>> (gdb) set $por_el0=0xffffffff77777777
>>>> (gdb) info register por_el0
>>>> por_el0 0xffffffff77777777 [ P15=??? P14=??? P13=??? P12=??? P11=??? P10=??? P9=???
>> P8=??? P7=rwx P6=rwx P5=rwx P4=rwx P3=rwx P2=rwx P1=rwx P0=rwx ]
>>>> (gdb) p $por_el0
>>>> $1 = [ P15=??? P14=??? P13=??? P12=??? P11=??? P10=??? P9=??? P8=??? P7=rwx P6=rwx
>> P5=rwx P4=rwx P3=rwx P2=rwx P1=rwx P0=rwx ]
>>>> (gdb) p/x $por_el0
>>>> $2 = 0xffffffff77777777
>>>> (gdb) set $por_el0=0x57
>>>> (gdb) info register por_el0
>>>> por_el0 0x57 [ P15=--- P14=--- P13=--- P12=--- P11=--- P10=--- P9=--- P8=--- P7=---
>> P6=--- P5=--- P4=--- P3=--- P2=--- P1=rw- P0=rwx ]
>>>> (gdb) set $por_el0=0xf7f7f7f7f7f7f7f7
>>>> (gdb) info register por_el0
>>>> por_el0 0xf7f7f7f7f7f7f7f7 [ P15=??? P14=rwx P13=??? P12=rwx P11=??? P10=rwx P9=???
>> P8=rwx P7=??? P6=rwx P5=??? P4=rwx P3=??? P2=rwx P1=??? P0=rwx ]
>>>> (gdb)
>>>
>>> Looking at the output above I think it is a bit hard to read.
> 
> I think part of the reason for it being hard to read is that the output
> is very wide.

Indeed. I mean, as an overview it's fine. But it really depends on the 
most common use case for this register.

What I want to steer clear from is something like we have for SVE 
registers. It is a barrage of text that isn´t very easy to use.

> 
> One way to address this is Srinath's suggestion below to not print
> zeroed keys. Another would be to improve the output of the flag type to
> add line breaks when the terminal's width is reached, as is done when
> printing array values.
> 
> Another option would be to use a struct rather than a flags type. Then
> there would be one type per field, and it would be possible to display
> (and set) only one key.
> 
> Not sure which of them I prefer. The struct idea has the advantage of
> letting the user easily set protection keys individually. OTOH it's
> not printed isn a very compact way.
> 
> If easily displaying/setting individual keys isn't that important, I
> think I slightly prefer not printing zeroed keys as Srinath suggests,
> possibly coupled with adding line breaks when the line is too long, to
> address the case of having many keys set in the register.
> 

Good suggestions. I'd say if users want...

- An overview with permissions, then print what we have above
- To use it as a mask, we should have the raw value
- To read/write individual P<x> entries within the register, then we 
should have pseudo-registers that map back to por_el0.

The pseudo registers would leave the interpretation of the raw values 
out of the XML, therefore remote stubs wouldn´t need to pass that sort 
of information.

Stretching it a little bit, remote stubs could even send a modified 
version of these fields in the XML and gdb would start printing 
something else.