From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ia1dGylUZGraaywAWB0awg (envelope-from ) for ; Sat, 25 Jul 2026 02:14:01 -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=LuxEgJNh; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 68EDF1E09E; Sat, 25 Jul 2026 02:14:01 -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=unavailable 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 56A921E099 for ; Sat, 25 Jul 2026 02:14:00 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E1BD94BA2E29 for ; Sat, 25 Jul 2026 06:13:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E1BD94BA2E29 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=LuxEgJNh Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 38E984BA2E15 for ; Sat, 25 Jul 2026 06:13:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 38E984BA2E15 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 38E984BA2E15 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::529 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784960014; cv=none; b=IKAIDZSQNtiZbZfq3siAVTeQh++L3M2Ckhn7vRKS+M5aPTZl3Ln57msvKL3o6qXTVNTR4kigm2vPi1d9wCn2my5yjylmBB9cy9ZgkM3dr5Ghqp8Bi29B6wAR1ZxKSvLaw1nSAJiCVDXjm3o8kF9JKKzCxMDcqAkznSWXzdtZXb8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784960014; c=relaxed/simple; bh=uqjaNFyvCOPijQgUXvE7Hr6MOg/jxmJlCsRelcWqWs0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=K6mjh+EvAVBxmVp8RPeGkK5GyMX6UcC2SxFeahnAL38k/IC4wa6S9z+APMMU6zl5J/EP9lKJsNEbwD9pF+GSD27SXCk6Tz3/zxf3w9GBke0HPkSKBgAo0BFDkS2oFS/JGkkdCwan69yHrh+hRku6boVSELZC/tR/+uGC7YiTFBw= 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=LuxEgJNh DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 38E984BA2E15 Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-c999f162c9aso813452a12.3 for ; Fri, 24 Jul 2026 23:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784960013; x=1785564813; darn=sourceware.org; h=content-transfer-encoding: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=4yMwc4pXTXoF47pJb5hifx4W693aE8g1eEaLq0kLNP4=; b=LuxEgJNh5AucjSluzBN3JNGGwJVPsa1RSrezKZtvMJJOmQf5xHkRr6tC7Hs1QtzyRt ImeF++QYzjtJfpY9ugsuayBlChy0bFKdX/KICg6VE8Pe5RY3DnGjavji2M9QwyaNQaP+ rvw/AcLHfMhD0qrzerNpw3NW6xBREHwVpL17NPxq92ZCr/oNHy9aJWUj+3ghoypnYRGQ wp9XOeeKErvEICZZ3HxFQjVpfdVOOU57kMeP6vu0iDTwoVFi67CYccZlTAaKXodDdyKo 48uijQs9W4sZHZIb1Sq9k512BUss6VFRlEpZ0BdTeoc63s3C4LYTpAtuz2MMEya3Hxh/ oOqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784960013; x=1785564813; h=content-transfer-encoding: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=4yMwc4pXTXoF47pJb5hifx4W693aE8g1eEaLq0kLNP4=; b=iF/Zhwj1yMlcchB3p6AKwsoJD1LgJ929+Js1F8uhTxYPHhQaMBDqYzaMtLcIOQSh7P vtRDhPDWW3te/Ojx3Q3DjqyPfGAp/9UAQ0mOi0TauhUsFP/ws84E2Zx+9pOy+ZIkK1N0 ECZutvzzayHEE0Ypvh148/JQXNg7c5kvb++Bwv+DM+qYkpeDLETIiCScLzwFo2V7Zcai 9AKPqzib1n4c+Q6nN7wkXf/f6NC10/okjmu5aHh6c/BJibofGKO4cHX1WKxFndmuEEOZ /6+FAwRavosm52rdYU8J8WkzVsvkI6lOxrLsE6RdnqBXAfJ9ipld7g5LwkG4QyQhP7XH vABA== X-Forwarded-Encrypted: i=1; AHgh+RrIkOoUjMU3bBf3dbCisuJ0kYgG7kxq8nhzUr3lM2UvfgSfqxQy9IEisyN6khb0W0SlMbzfDjPGbCRn7A==@sourceware.org X-Gm-Message-State: AOJu0YzYiTpC0Nm83NLhCdnjkGRzB/Al51prjYRcmDXQF376S9nfJ+bn By2dwyTWiQfDWGelXs6ULdRGpBnO/9mUp5Zrh6aUgrLXIsoJfzJQ6T9mCMHQJCivF+8= X-Gm-Gg: AR+sD11dXS98DOypb2RM0LanvDKliQVgjlmZiQ+6wp0unww4Y8Se1ZL7xIGajbjymCk 7MKrYzFvJMIVAgs9du1XlOuOMplt1cw5nizU2mR0c0E7W4b3YDXBoqQgz65nei8UtxYi1aEcrCr zptD3T8tailuRtvCEgDegjDLK/T0juJaELCnptUFpDjhFXWE0cMu+85Hjq2z096bGlxYTR4/3pi FCpHAnGLXIQlfurkl4PdHiuhssAOZoDZ7J6f1nwW+jqdtBg+WsuqTa+fnPiXwdNaPl5EaAY8yTN wlTmk//i35gBTsJRdXoSkgwKLzjZqpogDLwxdL1xN9tjXFvRAl1eWVLPa4q+jyfScm7u/SJfh8/ lnQr09FTySq9S1rnHSPOp0T26nqPrPtQ/fU9zZqPVQ1Zrwi7EEUD5cN8l3vjFxLwUkCW1zDYhpt yKQudH2Mq3ZD26+acC/NFtSXY= X-Received: by 2002:a05:6a21:9204:b0:3c3:8ce8:203 with SMTP id adf61e73a8af0-3c67e0b93aamr1133795637.50.1784960013037; Fri, 24 Jul 2026 23:13:33 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-314bc3e1290sm6481931eec.1.2026.07.24.23.13.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 23:13:32 -0700 (PDT) From: Thiago Jung Bauermann To: Srinath Parvathaneni Cc: Luis , "gdb-patches@sourceware.org" , "guinevere@redhat.com" , Ezra Sitorus , Matthieu Longo , "simark@simark.ca" , Yury Khrustalev Subject: Re: [PATCH v3 1/5] [PATCH 1/5] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE In-Reply-To: (Srinath Parvathaneni's message of "Thu, 23 Jul 2026 09:29:59 +0000") References: <20260714201530.78374-1-srinath.parvathaneni@arm.com> <20260714201530.78374-2-srinath.parvathaneni@arm.com> <29190e6c-7d33-4967-a21c-ed53cb1f43e2@gmail.com> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Sat, 25 Jul 2026 06:13:30 +0000 Message-ID: <87fr17lhpx.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Srinath Parvathaneni writes: >>> * p/x $por_el0 >>> * set $por_el0 =3D >>> >>> Example: >>> (gdb) info register por_el0 >>> por_el0 0x7 [ P15=3D--- P14=3D--- P13=3D--- P12=3D--- P11=3D--- P10=3D-= -- P9=3D--- P8=3D--- P7=3D--- > P6=3D--- P5=3D--- P4=3D--- P3=3D--- P2=3D--- P1=3D--- P0=3Drwx ] >>> (gdb) set $por_el0=3D0xffffffff77777777 >>> (gdb) info register por_el0 >>> por_el0 0xffffffff77777777 [ P15=3D??? P14=3D??? P13=3D??? P12=3D??? P1= 1=3D??? P10=3D??? P9=3D??? > P8=3D??? P7=3Drwx P6=3Drwx P5=3Drwx P4=3Drwx P3=3Drwx P2=3Drwx P1=3Drwx P= 0=3Drwx ] >>> (gdb) p $por_el0 >>> $1 =3D [ P15=3D??? P14=3D??? P13=3D??? P12=3D??? P11=3D??? P10=3D??? P9= =3D??? P8=3D??? P7=3Drwx P6=3Drwx > P5=3Drwx P4=3Drwx P3=3Drwx P2=3Drwx P1=3Drwx P0=3Drwx ] >>> (gdb) p/x $por_el0 >>> $2 =3D 0xffffffff77777777 >>> (gdb) set $por_el0=3D0x57 >>> (gdb) info register por_el0 >>> por_el0 0x57 [ P15=3D--- P14=3D--- P13=3D--- P12=3D--- P11=3D--- P10=3D= --- P9=3D--- P8=3D--- P7=3D--- > P6=3D--- P5=3D--- P4=3D--- P3=3D--- P2=3D--- P1=3Drw- P0=3Drwx ] >>> (gdb) set $por_el0=3D0xf7f7f7f7f7f7f7f7 >>> (gdb) info register por_el0 >>> por_el0 0xf7f7f7f7f7f7f7f7 [ P15=3D??? P14=3Drwx P13=3D??? P12=3Drwx P1= 1=3D??? P10=3Drwx P9=3D??? > P8=3Drwx P7=3D??? P6=3Drwx P5=3D??? P4=3Drwx P3=3D??? P2=3Drwx P1=3D??? P= 0=3Drwx ] >>> (gdb) >> >>Looking at the output above I think it is a bit hard to read. I think part of the reason for it being hard to read is that the output is very wide.=20 One way to address this is Srinath's suggestion below to not print zeroed keys. Another would be to improve the output of the flag type to add line breaks when the terminal's width is reached, as is done when printing array values. Another option would be to use a struct rather than a flags type. Then there would be one type per field, and it would be possible to display (and set) only one key. Not sure which of them I prefer. The struct idea has the advantage of letting the user easily set protection keys individually. OTOH it's not printed isn a very compact way. If easily displaying/setting individual keys isn't that important, I think I slightly prefer not printing zeroed keys as Srinath suggests, possibly coupled with adding line breaks when the line is too long, to address the case of having many keys set in the register. >>Have you considered keeping the original register as it is and having >>pseudo-registers that print appropriately? >> >>If a user wants to see, say, P15, it doesn=C2=B4t help we print everything >>else along with it. >> >>The other alternative is having a python pretty printer that goes >>alongside the feature. >> > > Hi Luis, > > Thanks for the suggestions. > > The reason I chose to decode the register inline is that the raw 64 bit r= egister > value by itself is not particularly useful. For example, if we kept the o= riginal > formatting, the user would see something like: > > (gdb) set $por_el0 =3D 0xf7f7f7f7f7f7f7f7 > (gdb) info register por_el0 > por_el0 0xf7f7f7f7f7f7f7f7 17868022691004925943 > > Neither of hexadecimal nor the decimal value tells the user which protect= ion key > has which permissions without manually decoding each 4-bit nibble. > > Although the architecture defines POR_EL0 as a single 64 bit register, it > doesn't define separate P0-P15 fields. I introduced the P0-P15 labels > to identify each 4-bit nibble, since each nibble corresponds to one prote= ction > key's permission encoding. I agree that if the raw register value isn't useful, then it makes sense to use a more elaborate type for it. > We also considered only displaying nibbles that have at least one permiss= ion > enabled, while displaying "???" when the reserved fourth bit of a nibble = is set. > For example: > > (gdb) set $por_el0 =3D 0x57 > (gdb) info register por_el0 > por_el0 0x57 [ P1=3Drw- P0=3Drwx ] > > (gdb) set $por_el0 =3D 0xf7 > (gdb) info register por_el0 > por_el0 0xf7 [ P1=3D??? P0=3Drwx ] > > However, we thought that approach could be misleading because it hides the > remaining protection keys rather than explicitly showing that they are all > "---", please let me know if you feel this approach is better? I think this is better than the output in the commit message. Especially in the "info register" case where the raw value is also shown so it's not hard to see that ommitted keys are zeroed. Even with the print command, using print/x will show the raw value too. I have a couple more comments on the patch: >> diff --git a/gdb/arch/aarch64-poe-linux.h b/gdb/arch/aarch64-poe-linux.h >> new file mode 100644 >> index 00000000000..8623fa43b54 >> --- /dev/null >> +++ b/gdb/arch/aarch64-poe-linux.h >> @@ -0,0 +1,29 @@ >> +/* Common Linux target-dependent definitions for AArch64 POE >> + >> + Copyright (C) 2026 Free Software Foundation, Inc. >> + >> + This file is part of GDB. >> + >> + This program is free software; you can redistribute it and/or modify >> + it under the terms of the GNU General Public License as published by >> + the Free Software Foundation; either version 3 of the License, or >> + (at your option) any later version. >> + >> + This program is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + GNU General Public License for more details. >> + >> + You should have received a copy of the GNU General Public License >> + along with this program. If not, see = . */ >> + >> +#ifndef GDB_ARCH_AARCH64_POE_LINUX_H >> +#define GDB_ARCH_AARCH64_POE_LINUX_H >> + >> +/* Feature check for Permission Overlay Extension. */ >> +#define AARCH64_HWCAP2_POE (1ULL << 63) >> + >> +/* Data or instruction abort caused by Protection Key Violation. */ >> +#define AARCH64_SEGV_PKUERR 4 >> + >> +#endif /* GDB_ARCH_AARCH64_POE_LINUX_H. */ check-include-guards.py complains about the comment above: $ gdb/check-include-guards.py gdb/arch/aarch64-poe-linux.h gdb/arch/aarch64-poe-linux.h:29: wrong endif line $ gdb/check-include-guards.py --update gdb/arch/aarch64-poe-linux.h $ git diff diff --git a/gdb/arch/aarch64-poe-linux.h b/gdb/arch/aarch64-poe-linux.h index 8623fa43b549..d6e4a001cbf9 100644 --- a/gdb/arch/aarch64-poe-linux.h +++ b/gdb/arch/aarch64-poe-linux.h @@ -26,4 +26,4 @@ /* Data or instruction abort caused by Protection Key Violation. */ #define AARCH64_SEGV_PKUERR 4 -#endif /* GDB_ARCH_AARCH64_POE_LINUX_H. */ +#endif /* GDB_ARCH_AARCH64_POE_LINUX_H */ Also, nothing in this patch uses this file. It should be moved to patch 2. --=20 Thiago (he/him)