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

On 21/07/2026 22:57, Luis wrote:
> Drive-by review.
> 
> On 07/07/2026 16:48, Matthieu Longo wrote:
>> Memory Protection Keys provide a mechanism for enforcing page-based
>> protections without requiring modification of the page tables
>> when an application changes protection domains. [1]
>>
>> The "ProtectionKey" field may be present in /proc/PID/smaps x86_64
>> and AArch64 systems since Linux 4.9, when the kernel is built with
>> Memory Protection Keys support.
>>
>> Add a new 'pkey' field to `struct smaps_data', and populate it when
>> the "ProtectionKey" field is present.
>>
>> This prepares for displaying the protection key in 'info proc mappings'.
>>
>> [1]: https://docs.kernel.org/core-api/protection-keys.html,
>>       https://lkml.iu.edu/1512.0/03058.html
>> ---
>>   gdb/linux-tdep.c | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
>> index dbc69a5a7fc..d89c5ae8504 100644
>> --- a/gdb/linux-tdep.c
>> +++ b/gdb/linux-tdep.c
>> @@ -124,6 +124,7 @@ struct smaps_data
>>       ULONGEST rss;
>>     ULONGEST swap;
>> +  std::optional<int> pkey;
>>   };
>>     /* Whether to take the /proc/PID/coredump_filter into account when
>> @@ -1553,6 +1554,7 @@ parse_smaps_data (const file_reader_t<char> &freader)
>>         int mapping_file_p;
>>         ULONGEST rss = -1;
>>         ULONGEST swap = -1;
>> +      int pkey = -1;
>>           memset (&v, 0, sizeof (v));
>>         struct mapping m = read_mapping (line);
>> @@ -1653,6 +1655,16 @@ parse_smaps_data (const file_reader_t<char> &freader)
>>             mapping_anon_p = 1;
>>           }
>>           }
>> +
>> +      if (streq (keyword, "ProtectionKey:"))
>> +        {
>> +          if (sscanf (line, "%*s%d", &pkey) != 1)
>> +        {
>> +          warning (_("Error parsing %s's value in {s,}maps file '%s'"),
>> +               keyword, freader.c_filepath ());
> 
> If keyword has the trailing colon this will read...
> 
> Error parsing ProtectionKey:'s value
> 
> ... right?
> 

Yes, you are right.
Fixed in the next revision.

--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -1729,6 +1729,8 @@ parse_smaps_data (const file_reader_t<char> &freader)
            {
              if (sscanf (line, "%*s%d", &pkey) != 1)
                {
+                 /* Remove the trailing column when printing the warning.  */
+                 keyword[sizeof ("ProtectionKey:") - 2] = '\0';
                  warning (_("Error parsing %s's value in {s,}maps file '%s'"),
                           keyword, freader.c_filepath ());
                  break;

>> +          break;
>> +        }
>> +        }
>>       }
>>         /* Save the smaps entry to the vector.  */
>>       struct smaps_data map;
>> @@ -1672,6 +1684,7 @@ parse_smaps_data (const file_reader_t<char> &freader)
>>       map.inode = m.inode;
>>       map.rss = rss;
>>       map.swap = swap;
>> +    map.pkey.emplace (pkey);
> 
> Are we always unconditionally adding a key by design, even when no keys were found? Then we add the
> sentinel -1. Or am I missing something?
> 

Yes, my mistake. I should have checked on the sentinel value.
Fixed in the next revision.

>>         smaps.emplace_back (map);
>>       }
> 
> And I agree with Thiago. This patch should live alongside Srinath's series.

For the next revision, I actually display the value in the PKey column (no effective permissions or
overlay ones in this scope, just the PKey display for any version of Linux that expose it in
/proc/PID/smaps)

To do so, I refactored the code section in "if (mappings_f)". This refactoring relies on the
introduction of file_reader_t, so it would make sense to keep it in this patch series.
Please have a look at the next revision.

Matthieu