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

[Yury Khrustalev <yury.khrustalev@arm.com>]

On Fri, Jul 24, 2026 at 02:58:38AM +0000, Thiago Jung Bauermann wrote:
> 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?

PKey is a standard recognised term (see [1] for one example), so I think we should use it.

[1]: https://www.man7.org/linux/man-pages/man7/pkeys.7.html

> 
> > 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).

The idea is that effective permissions are always displayed while
overlay and any other future types of permissions are optional and
might not be present. I think having left-most columns always present
and aligned will make it easier to read and parse.

> 
> 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.

I think parentheses and another "permissions" word repeated on every
line will only waste horizontal space. The format of output will be
documented of anyone is unsure what those symbols mean.

> > 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?

I think the column should be just empty or have some placeholder like a
hyphen when mapping is not associated with a pkey.

> 
> > 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.

I agree.

Thanks,
Yury