Re: [PATCH v1 09/10] gdb/linux-tdep: parse ProtectionKey in /proc/PID/smaps
Yury Khrustalev <[email protected]> Fri, 24 Jul 2026 11:27:23 +0100
| Newsgroups | gmane.comp.gdb.patches |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Jul 24, 2026 at 02:58:38AM +0000, Thiago Jung Bauermann wrote: > Matthieu Longo <[email protected]> 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