From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YB8FEf7UYmrtyyoAWB0awg (envelope-from ) for ; Thu, 23 Jul 2026 22:59:10 -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=e7FGcf1g; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 378321E09E; Thu, 23 Jul 2026 22:59:10 -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 [38.145.34.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 62F5D1E033 for ; Thu, 23 Jul 2026 22:59:09 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 91D794BA23E5 for ; Fri, 24 Jul 2026 02:59:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91D794BA23E5 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=e7FGcf1g Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) by sourceware.org (Postfix) with ESMTPS id 84FD24BA2E2F for ; Fri, 24 Jul 2026 02:58:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 84FD24BA2E2F 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 84FD24BA2E2F Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::a36 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784861921; cv=none; b=ZHfjcXAFq28axDQR/3VbGkKcwI6tJn+iEfQ1iBS8cWdzw7t+1dH3zUrkbcTXlMHvdPLMUVP1LyA3xBcDE+5mNr7XEGtak7TNzILxEEdzJHEUNH+GDEtmfH/RKNYn+91vFhF4sXs6QxU8xU4AbN9v5AnNwAadR5lYaYpDvAwfC64= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784861921; c=relaxed/simple; bh=uL99E5rIN2/jRKRrW0XVr5O83DlCL0EfEyMS5NwWZEY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=C61O/7O34rpyqRvDOa3kXBSwumn3ci+eMqPngPQowronbKOdGdpN0gWD6Oy/JLsVFDgpBHHCU3g0LlgvGD9gLFu55h0V7AVj1yzJPNT0SmP8lwq/X5ItiFS/5p4XcVEISegv98GGLnvp6w2WjsubiFll3sRTuxqqkbzDHxEpQO0= 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=e7FGcf1g DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 84FD24BA2E2F Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-5bf95ade656so454971e0c.1 for ; Thu, 23 Jul 2026 19:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784861921; x=1785466721; 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=KAJ6eQY1q6eOdKvz2P29O8KAYFpPcLKZOZy2EvcWC4U=; b=e7FGcf1gkw2BqRxAg1zIMLc43R5Ri8WDyDHY3WeKZqS0/vPpRrkhPyRkLbevVMyhAn bByUGaQ3jdJoAnuSl+/6Enk8MMLipgMqRh8QA7PZNBjj2/jMmpZS/9ucAwoLPRUdRqCA AiPl2CJBlqAvn5YXmpoAHjs17aG9Usnj25OktMx3VJ7NaGdIFWFBjxuB7NIcUsMSlNNi F9wGRUkzURgpJ+UuV16/4NjMIap+IXeZwJhdtrInpa4eL1VkmubC+OCooub+MX+IaMDw 9vpefl+ANsFEyoOeMIRqvKSv0RhNaIgAAP6B07mwYAlroRVmiLdvX4+FkKq3jvj+Bb7r TuBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784861921; x=1785466721; 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=KAJ6eQY1q6eOdKvz2P29O8KAYFpPcLKZOZy2EvcWC4U=; b=px+4ZGYUlZN1k1Kb+MAYuouyeK9GICNKxQIfam5sM/bvJW1YmaX6j2qR8euZjXLV8l tN6cpLj6TI/2UyUfiqbeqR19E8YnQU0vexOnLrlt6wQ6wotYHG7Hn8qKaZsAHioOPlYt Jd4eybMcoEsYIgTBeVIs6WXK+JxzmeUFSdLtHCbdHublhTw3I8V2Ru9hqJWfnIYutFyU rc7kZ+Gh4Rsrif7NNUFyOaRo2m3uTQb83II9iTUXcTc5qGCmGkiy7M0zcZFimgVtSfdw tzK4K4k5AkryIt/GJKCBwMSLS0Op1J7e0sITn6bEYZoOcL7jhi+5IXHFblAIFN6Qm57H v2zA== X-Gm-Message-State: AOJu0YyL+A/d/KQjEMrIfkDtmN6aYgxNlloZ6ms7ncCpFEAmBQVe4cJv xuYnPdNCNti6t+iVnsRLVSQz3bCu/niwmwnu0BFN1kaFRc2fCBxAM/gqhRSccLUP9QT8k/QUoJt E1vsk X-Gm-Gg: AR+sD12AdURe+J7mcz1fycY4XDUWepx9oIcxAcmgYQJAxJCd6pvcLoPa0mHPh08v0nA 7kjbd/JNS3CMbRWb9GXTSkDslTPNxYJXXf34jpnOCZk8Mi3UROdU2RMKrIMVcYWUYJeiclUf+KE yNUdSkvVnKgGuZSLy0sAYm+y2LoWYfGuVmBwP+J6UIHecyer6HDcomPLf1VCv5mHpoHrC4WZEer uKwm68cuJ+ZysTCG7nsSYUm6E+t8ftKyHMksbcJwrWpcOSHal1srP4vwAeBMjzOOO9Hxt0rQ316 +w67atXs92nzaZncGUKmimf7ElhlQLAC7fU4dtkWm28vvnGD1NlGMMnM9ol0Me+aWIHJ8IvlOLt vnT18F59SU/+TgfSMFGPtf/rmzXMzgPD+l0z7KQ+9sgtadOXjatwPF2gGto65wTOq+nNR9HGmux Z0X4RbRnAyvKvL X-Received: by 2002:a05:6122:2895:b0:5a1:fbbd:6bd0 with SMTP id 71dfb90a1353d-5c2da05452bmr2857106e0c.5.1784861920844; Thu, 23 Jul 2026 19:58:40 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c2c62be0c8sm7688376e0c.7.2026.07.23.19.58.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 19:58:40 -0700 (PDT) From: Thiago Jung Bauermann To: Matthieu Longo Cc: gdb-patches@sourceware.org, Luis Machado , Luis Machado , Andrew Burgess , Yury Khrustalev , Pedro Alves , Tom Tromey , Srinath Parvathaneni Subject: Re: [PATCH v1 09/10] gdb/linux-tdep: parse ProtectionKey in /proc/PID/smaps In-Reply-To: (Matthieu Longo's message of "Tue, 14 Jul 2026 10:29:41 +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> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Fri, 24 Jul 2026 02:58:38 +0000 Message-ID: <87wluldrfl.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 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? > 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). 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. > 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? > 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. -- Thiago (he/him)