From: Yury Khrustalev <yury.khrustalev@arm.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: Matthieu Longo <matthieu.longo@arm.com>,
<gdb-patches@sourceware.org>, Luis Machado <luis.machado@amd.com>,
Luis Machado <luis.machado.foss@gmail.com>,
Andrew Burgess <aburgess@redhat.com>,
"Pedro Alves" <pedro@palves.net>, Tom Tromey <tom@tromey.com>,
Srinath Parvathaneni <srinath.parvathaneni@arm.com>
Subject: Re: [PATCH v1 09/10] gdb/linux-tdep: parse ProtectionKey in /proc/PID/smaps
Date: Mon, 27 Jul 2026 09:22:42 +0100 [thread overview]
Message-ID: <amcUiF-hSF-qKlmC@arm.com> (raw)
In-Reply-To: <87zezfk1we.fsf@linaro.org>
On Sat, Jul 25, 2026 at 06:40:33AM +0000, Thiago Jung Bauermann wrote:
> Yury Khrustalev <yury.khrustalev@arm.com> writes:
>
> ...
>
> >> > 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.
The point of the empty column (that is only shown when pkeys are
supported) is that it would show that none of your mappings use any
pkeys. I think this is useful piece of information. E.g. if I expect to
see a key but due to a bug it's not used, I don't want to not see this
column at all because I would think that my version of GDB does not
support it or something.
next prev parent reply other threads:[~2026-07-27 8:36 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 15:48 [PATCH v1 00/10] gdb: bugfix 31207 and various refactoring in linux-tdep Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 01/10] gdb/linux-tdep: change linux_fill_prpsinfo to return bool Matthieu Longo
2026-07-09 6:26 ` Thiago Jung Bauermann
2026-07-09 12:23 ` Simon Marchi
2026-07-27 14:38 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 02/10] gdb: rely on the first alive thread TPID when reading Linux procfs files Matthieu Longo
2026-07-09 6:29 ` Thiago Jung Bauermann
2026-07-13 9:11 ` Matthieu Longo
2026-07-09 14:24 ` Simon Marchi
2026-07-14 15:47 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 03/10] target_fileio_read_stralloc: add an optional length parameter Matthieu Longo
2026-07-09 6:30 ` Thiago Jung Bauermann
2026-07-13 15:26 ` Matthieu Longo
2026-07-24 2:50 ` Thiago Jung Bauermann
2026-07-27 14:52 ` Matthieu Longo
2026-07-29 1:57 ` Thiago Jung Bauermann
2026-07-21 21:28 ` Luis
2026-07-27 14:48 ` Matthieu Longo
2026-07-27 14:53 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 04/10] gdb support: add gdb::replace algorithm for iterators and ranges Matthieu Longo
2026-07-09 6:30 ` Thiago Jung Bauermann
2026-07-10 21:21 ` Kevin Buettner
2026-07-13 15:51 ` Matthieu Longo
2026-07-21 21:33 ` Luis
2026-07-27 14:58 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 05/10] gdb: introduce helper class file_reader_t Matthieu Longo
2026-07-09 6:33 ` Thiago Jung Bauermann
2026-07-13 17:17 ` Matthieu Longo
2026-07-10 21:43 ` Kevin Buettner
2026-07-13 16:31 ` Matthieu Longo
2026-07-13 15:50 ` Schimpe, Christina
2026-07-13 17:12 ` Matthieu Longo
2026-07-22 16:36 ` Joos, Christina
2026-07-27 15:13 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 06/10] gdb/linux-tdep: migrate linux_info_proc to file_reader_t Matthieu Longo
2026-07-09 6:35 ` Thiago Jung Bauermann
2026-07-13 17:20 ` Matthieu Longo
2026-07-21 21:43 ` Luis
2026-07-27 17:11 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 07/10] gdb/linux-tdep: migrate linux_find_memory_regions_full " Matthieu Longo
2026-07-09 6:36 ` Thiago Jung Bauermann
2026-07-14 8:40 ` Matthieu Longo
2026-07-24 2:51 ` Thiago Jung Bauermann
2026-07-21 21:47 ` Luis
2026-07-27 17:14 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 08/10] gdb/linux-tdep: migrate parse_smaps_data " Matthieu Longo
2026-07-09 6:41 ` Thiago Jung Bauermann
2026-07-14 8:49 ` Matthieu Longo
2026-07-24 2:52 ` Thiago Jung Bauermann
2026-07-21 21:49 ` Luis
2026-07-27 17:17 ` Matthieu Longo
2026-07-07 15:48 ` [PATCH v1 09/10] gdb/linux-tdep: parse ProtectionKey in /proc/PID/smaps Matthieu Longo
2026-07-09 6:42 ` Thiago Jung Bauermann
2026-07-14 9:12 ` Matthieu Longo
2026-07-14 9:29 ` Matthieu Longo
2026-07-24 2:58 ` Thiago Jung Bauermann
2026-07-24 10:27 ` Yury Khrustalev
2026-07-25 6:40 ` Thiago Jung Bauermann
2026-07-27 8:22 ` Yury Khrustalev [this message]
2026-07-29 1:10 ` Thiago Jung Bauermann
2026-07-21 21:57 ` Luis
2026-07-27 17:54 ` Matthieu Longo
2026-07-07 15:49 ` [PATCH v1 10/10] gdb/linux: add helpers to read AT_HWCAP3 and AT_HWCAP4 Matthieu Longo
2026-07-09 6:44 ` Thiago Jung Bauermann
2026-07-21 21:58 ` Luis
2026-07-27 17:32 ` Matthieu Longo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amcUiF-hSF-qKlmC@arm.com \
--to=yury.khrustalev@arm.com \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado.foss@gmail.com \
--cc=luis.machado@amd.com \
--cc=matthieu.longo@arm.com \
--cc=pedro@palves.net \
--cc=srinath.parvathaneni@arm.com \
--cc=thiago.bauermann@linaro.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox