From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WeXLHn9aZGr4cywAWB0awg (envelope-from ) for ; Sat, 25 Jul 2026 02:41:03 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=iC25Qo7E; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 772051E099; Sat, 25 Jul 2026 02:41:03 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8665B1E099 for ; Sat, 25 Jul 2026 02:41:02 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 56A3B4BA7997 for ; Sat, 25 Jul 2026 06:41:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 56A3B4BA7997 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=iC25Qo7E Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id A26574BA2E12 for ; Sat, 25 Jul 2026 06:40:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A26574BA2E12 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A26574BA2E12 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::632 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784961636; cv=none; b=Wz4MEhE2fE/Q8l3gD+H3NDxGvf1v00Y3IJY0jET5xrl9QORp9E52XerSsPbFtPVvtG99hLyzzbhHV+JPbOEWB28QjJliNGV9chA8ruwDgodSQoG6fFTHBFoWACBI3OyNIneOQLP4BE3N1s5+F2uGFoCY5Kz9s2vB8praGswf9ug= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784961636; c=relaxed/simple; bh=D2/xl0LmS+7el/pHCoiAzlgjr4uaVky9QimzdsSIK+8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=kjJZdyudTarnmjSAIrwSFxpEpVc59eIWovSVumbr2NZGt7X5zRUQIeBkYX+lxOGuF8MLlB7m57ms+9AIGS26EDAtjyAubvCoieXb/6EHOu/dncHuxJ7F7zbkHL7V57+y5oVvNQDhU4L3NZ6Xuasp37uUcPh30vaHNNRzmQUSIbg= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=iC25Qo7E DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A26574BA2E12 Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-2ceae1ed204so12356365ad.0 for ; Fri, 24 Jul 2026 23:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784961636; x=1785566436; darn=sourceware.org; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=JsPNPX1OvAdgpHRU4AncNnLXoUyxnBQ4t1W19nddL2A=; b=iC25Qo7EPALVOe3HLa83F72DaLQwvIjB4tWcen6DWqsXn+TagGCngQs5YC+0KASAuw 7fuD36I0UreyvYAzQmLh0oD+mycFMMa18ebELo1QQB8KbcxEDUKAE2jJ8WPnqVaYX1UM q3rJIxAFZlQYL5ckOmauHg6P16cNSrtChkyhURgaS8twpFw9yJ0Ak8lTm6QTyiD4qhsC JnTiC+HYEoRgh7BEQlTKPte4oG8vcsFMAguSMzhFlrVMDrYVE2K6BB94d5ls6Dblu994 tf2WueHtl417gdpN0xqDq7HmLtqBBKPovbuvX6mx1llD6aqmGhpQhsAGbBk/Wq0rGUdQ NexA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784961636; x=1785566436; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=JsPNPX1OvAdgpHRU4AncNnLXoUyxnBQ4t1W19nddL2A=; b=bbxad0fwrIAe2bHskHw8NwsT8BTN39p16UlB39pez2lheUDqnWLy4EdNmW+uOgJy9W 8UXLAgMKbQpFyuR2+6BSJ8SRNCMhr2JMvqLVeW4zthp5H+cAL0T1P4zspvVipLhsqBPQ 4Ob7DWAdwxLkMlz8hjAYKE4HDKAIEEKP1FJd/RB3JUlvuKGE50o89n9m4zM+6KnQGQgF J65BhLcXEYV+RyDxG/5GSqTH/BA/XYhsb/136ufrvk6uVm+xOSiEaTFkVSNXnOJfgK1c Le7LAfPOhu7QeApHesdSgCUW64kew0fmPcdytCWkVZq8JFrlQsK2jJi2WKX2IcGGGtnN SWsg== X-Forwarded-Encrypted: i=1; AHgh+Rrqc93fxG2X5UsSbhQy7vT2md1FDZl4IsEtkFMBYGLgaU0TvY8ZmYcbK2Pz8oluQWV5Nc+1z/nPEPIj1w==@sourceware.org X-Gm-Message-State: AOJu0YyrZMD7kHitLjm78xNMr/j10wI1/fTasyAuEiTjUONx2ohSd9rS Za4WlKlL7YUvkX5/25BLhQmgeFThqaJrbNc5WsrLnXobuZib9oqGLH7Tf4CcU0mLstw= X-Gm-Gg: AR+sD13zQPCTP5UcH8yIOElnYzYVHSBIRmJuULQDhZ1RiMNpPrVKUafCyIMszoBpkik nPSEm5iJtrDRYeEnkdUTxwblSkqkEcT+aw1K8hIf638vWzZfcf+H45fN9wqz7oSGttg91YqW9De ycU2xu6Hj92sfC6zB5w88gTvm3qPwcEUZyndtsOmKD5ScuN4Qrmw5BL+2FVyifeBgDxhFQZKbYX DC6j/xLqhr2hgHvvLnQW8tSSOjAYj2+ykTIUgyY3npi3FxFnDaJUDQuX+rTScEoPx19OwDtrp18 AbFtf6LeDaZy/tTh1bKw2sksPJ9zHoCkqJXVC7ScQQ673dM0WYz/E4+kwCcF7I/w0Ye0+NLIhBo k8KO41rTqtFrtw+gKoZN//v3JsBi5nUKu07ZyWprM+3a/FM1UKoc9NhXwexhA6LKnK03VxdDDIb 7saP9QgtUR0PW7 X-Received: by 2002:a17:902:eccc:b0:2cf:8131:75f3 with SMTP id d9443c01a7336-2cfde683793mr13875635ad.7.1784961635518; Fri, 24 Jul 2026 23:40:35 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-314bc3e1285sm7143715eec.5.2026.07.24.23.40.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 23:40:35 -0700 (PDT) From: Thiago Jung Bauermann To: Yury Khrustalev Cc: Matthieu Longo , , Luis Machado , Luis Machado , Andrew Burgess , "Pedro Alves" , Tom Tromey , Srinath Parvathaneni Subject: Re: [PATCH v1 09/10] gdb/linux-tdep: parse ProtectionKey in /proc/PID/smaps In-Reply-To: (Yury Khrustalev's message of "Fri, 24 Jul 2026 11:27:23 +0100") References: <20260707154900.94542-1-matthieu.longo@arm.com> <20260707154900.94542-10-matthieu.longo@arm.com> <87qzlczms3.fsf@linaro.org> <042de0a8-d0e4-4ad3-880a-684ab6a22077@arm.com> <87wluldrfl.fsf@linaro.org> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Sat, 25 Jul 2026 06:40:33 +0000 Message-ID: <87zezfk1we.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Yury Khrustalev writes: > On Fri, Jul 24, 2026 at 02:58:38AM +0000, Thiago Jung Bauermann wrote: >> Matthieu Longo 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)