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

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

Yury Khrustalev <yury.khrustalev@arm.com> writes:

> 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

Ah, even better. PKey is good then. Thanks for the reference.

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

Ok, that makes sense. I'll only note that parsing isn't a concern,
because the regular GDB output is for humans. For parsing GDB has the
Machine Interface.

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

Ok, makes sense too.

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

I don't see much use for an empty column (or one containing only
placeholder values), but I also don't feel strongly about it.

-- 
Thiago
(he/him)