Re: [PATCH v1 09/10] gdb/linux-tdep: parse ProtectionKey in /proc/PID/smaps

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

Matthieu Longo <matthieu.longo@arm.com> writes:

> On 14/07/2026 10:12, Matthieu Longo wrote:
>> On 09/07/2026 07:42, Thiago Jung Bauermann wrote:
>>>
>>> There's nothing in this patch series that uses the parsed pkey, so IMHO
>>> (other maintainers may disagree) it makes more sense if this patch is
>>> committed together with a patch that makes use of the field.
>> 
>> Nothing uses it yet because it is still unclear how to expose it to the users.
>> I assume that "info proc mappings" is a good place to do it.

I agree.

>> As a reminder those are the existing columns:
>> Start Addr         End Addr           Size               Offset             Perms File
>> 
>> Should we add a new column "Protection Key" or "PKey" between "Offset" and "Perms" ?
>> What do you think ?

I like the idea. A short column name is better to avoid wasting precious
horizontal space. I think "PKey" is hard to guess if one isn't familiar
with the hardware feature, so I'd suggest "ProtKey". What do you think?

> Additionally, if we were to print the permissions associated with a PKey, what do you
> think about
> the following view ?
>
> Start Addr         End Addr           Size               Offset    PKey     Perms File
> 0x0000000000400000 0x0000000000483000 0x83000 0x0 0 r-xp /path/to/file
>     ...
> 0x00000000004a2000 0x00000000004a7000 0x5000             0x0       1        rw-p
>     Thread 1: effective: r--  overlay: r--
>     Thread 3: effective: rw-  overlay: rw-
>     Thread 4: effective: r--  overlay: r-x

I like it. Just a few comments:

> Effective being the effective permissions resulting from the ANDing of the base
> permissions (coming
> from "Perms") AND the overlay permissions attached to a thread (permissions associated to
> the PKey.

Maybe it's just me, but displaying the overlay permissions after the
effective permissions makes me think that the latter are the actually
effective ones (I guess because English is a left-to-right language).

So to me it's more intuitive either if the effective field comes later,
or alternatively if there's something to indicate that overlay is not
the main field. E.g., by using parentheses:

    Thread 1: effective permissions: r--  (overlay: r--)

Also, as seen above I think it's clearer if the word "permissions" is
added.

> The look-up of those overlay permissions is platform-specific).

Considering that there are differences in how protection keys are
implemented in different architectures (e.g., IIUC only Arm has overlay
permissions), the whole "effective: r-- overlay: r--" part of the line
should be printed by a gdbarch hook.

> If no protection key support exists on the target, the PKey column would not be printed.
> Same for the threads' permissions (effective and overlay).

Also even if protection key support is available, if there's no
protection key set for any mapping then the column shouldn't be printed
either. Or is there always a key associated with every mapping?

> Does this approach look fine to you ?

Yes, I like it.

> Does it overload the view ?

If the additional fields only appear for inferiors actively using
protection keys, I don't think it overloads the view.

> Should the dumping of effective and overlay permissions be part of a generic or
> platform-specific
> command ?

Considering that several architectures provide this feature, I think it
should be part of a generic command.

-- 
Thiago
(he/him)