From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2flmMDQEZWqoVy0AWB0awg (envelope-from ) for ; Sat, 25 Jul 2026 14:45:08 -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=pHbzW7Y7; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C26C11E033; Sat, 25 Jul 2026 14:45:08 -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 044A41E033 for ; Sat, 25 Jul 2026 14:45:08 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AEBCB4BA2E2E for ; Sat, 25 Jul 2026 18:45:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AEBCB4BA2E2E 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=pHbzW7Y7 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 3BBEB4BA2E15 for ; Sat, 25 Jul 2026 18:44:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3BBEB4BA2E15 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 3BBEB4BA2E15 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::635 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785005080; cv=none; b=VFBptNGXdRm51b34RCJR7OTPUeU7cQPM1q+7MOANS6qVRawIDkQFKr0mq3jdSklw+83UzgDzsyzAB+VoJIc68rTBXMplNFtZPzzpjvRalIfvpKIiKKmSvUW+6RBrmjI1vsUZYXNYGrSX/o86ylnhjHdm5SZ96OK+7yqHJMuXxZk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785005080; c=relaxed/simple; bh=VN7q428jfhufF0BKHrQ6NmlyMIqklMkmekZhKqiKWNU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xcGkwM7CXOt2aaZ2ylN9A78Payg+q4ymgy0J8siP6e1BpeKI5Q3jAuMM1yTYz0DDOJjc/t0unsSkegOsOZDyVKFnmtet8iUunmVG4L4Qd/PZ4NEm+0nVWCJHoAuAkuYpHhB65i7f9lOGM+d24t0TvEjAahT82eBmAoQLC97OBoY= 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=pHbzW7Y7 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3BBEB4BA2E15 Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-2cad8076b01so16241505ad.2 for ; Sat, 25 Jul 2026 11:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1785005079; x=1785609879; 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=BFv8mwWOX8Cr+/kFMyWhcNeJzVr47ZXfFg+agtNGYe8=; b=pHbzW7Y7bbfFrJ/8cKC/IeTbCpwsLFLxaUa1Wh1nekWf/44kkfXngu/Xnz78S+O8d5 aS+qmZZPphTC6O/neFfa/lcgdfaWPSjl2NRNToHkb58nA/JedYg5xp/xOYZsq/rnNF5q 5rFvxGJVuUkhiHtYWGfVXUDZ60NHaRls1fxkNcjnB+1lWPIT0qIr1jPqzdEfyYiyWq+e 0c1EVU/fgqh/lIcdr7iMm2VBHk0JXwWVPb3Et3Bi2ezhFyZ5LGLcQpkEj+If4ha/sKd/ ENkDMV9nMjGfGQ/DHlloAEDbmw1Pm35RR1gFfmbgMMCNnXnSY4XL2S04Ff9Awc88mBX/ AOtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785005079; x=1785609879; 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=BFv8mwWOX8Cr+/kFMyWhcNeJzVr47ZXfFg+agtNGYe8=; b=fvOmQDJm7a9toakl/qFHHmPmco5ICdz64zRI2Jr37yCIqmjkjHaypUClNbJs2NfxH+ BRnGJTzyMm11wzf2Zg1/daeqWzIB/YofQTpnplZIldCupeG0eM3XLsblR/HvXsKtbROc O6vNBA/yqo8GwKpwyFOtsDlCa5Ea+B6dArVQaiNduc5OFdo+Hnx0kWtJg4M8iqa8nspd vDc5i6K3a9j4AlX+8Sw3756856RDziPq7+oxpPfw0PMAvQaoEV7Vd55IUVMSovkuC5ce ftZj/eKUSnvfazLAaNEr84F8UD54+bq87MDt/O5aGeNeT2Fj7XXuC+agTzjG8vduRTsm HTKA== X-Forwarded-Encrypted: i=1; AHgh+RrV9Hh/xjv7X/RDgyzdH2F0AzbyoWE0BK/ZfUffVtkfDjP3L7ohH5OmyobVxJwavlAThcaLEo/SWdzfiw==@sourceware.org X-Gm-Message-State: AOJu0Yxs/Sf1566IZBYVdJe21nwVBBpSfLNzQhTEIez0Xt3WDjv+didl 7S8kZSZwc+j6u8qMHW8wXERntdzhJyUanCO3CzG8a5NGoWxgqoyHBQjhjEvI8F6/X0A2sr6BYYx /IHc6 X-Gm-Gg: AR+sD13c+zmNE5HVcgp2Ld5cP5qJK2XZlR8/LGqNLdQJPnl8wsqzyvj00z2QfgET90z 9TEJmRCfGGCkYqfjTaumMZ7CWTcmkk6TAchUQR5BYeMbjiS7idcswatgJ91dKKANECuNulgZpwu B/o6FjKUZ57cG42BRhhLFWNJoso0oq0zHo0nQkvBOWWr6g5AU65632zHsu3Rm+wpkamRpPkP3cV 4guTeXMfwXQX6EWmi1kEigE5bb7tBKGUwYOYnuX+4kVW5Cg5pDXazT04ocEFkV5tdS9irND9vcp OZAD9wsqUmg6Ot7mLCoHBT5aT/U2tXhZ25VVuo4GdMH2zBifqS8HnB7BVi5DmnzeBA7lxnVN9nA H/llSPbG1T6vhimqjslw+LirTDt3du7mI4hU3a+SwO1dT+c+RGx4Cnlf02SQDN1/I6tgXB5+qOB +TMjnIfI8uXpEgT0/7vPnpuW8= X-Received: by 2002:a17:902:d48b:b0:2bd:8395:fedd with SMTP id d9443c01a7336-2cfde868d4amr27316335ad.37.1785005078829; Sat, 25 Jul 2026 11:44:38 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:33bc:f32e:9aa5:b915]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-314bc3e127asm22831159eec.2.2026.07.25.11.44.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Jul 2026 11:44:38 -0700 (PDT) From: Thiago Jung Bauermann To: Luis Cc: srinath.parvathaneni@arm.com, gdb-patches@sourceware.org, guinevere@redhat.com, Ezra.Sitorus@arm.com, Matthieu.Longo@arm.com, simark@simark.ca, Peter Maydell Subject: Re: [PATCH v3 1/5] [PATCH 1/5] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE In-Reply-To: (Luis's message of "Sat, 25 Jul 2026 08:37:35 +0100") References: <20260714201530.78374-1-srinath.parvathaneni@arm.com> <20260714201530.78374-2-srinath.parvathaneni@arm.com> <87bjbvlhey.fsf@linaro.org> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Sat, 25 Jul 2026 18:44:35 +0000 Message-ID: <87tspmkiy4.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 Luis writes: > On 25/07/2026 07:20, Thiago Jung Bauermann wrote: >> Luis writes: >>=20 >>> On 14/07/2026 21:15, srinath.parvathaneni@arm.com wrote: >>>> From: Srinath Parvathaneni >>>> Add support for the FEAT_S1POE POR_EL0 register on AArch64. >>>> This patch adds POR_EL0 to the AArch64 register set and reads/writes it >>>> using the NT_ARM_POE ptrace regset. >>> >>> Just a general comment, but por_el0 is unfortunate naming for a userspa= ce register. But >>> alas, it's been done that way in the Linux kernel as far as I can tell. >> Do you mean the _el0 suffix? We had a discussion about it here: >> https://inbox.sourceware.org/gdb-patches/87a4sgikk4.fsf@linaro.org/ >> Srinath responded: >>=20 >>> That said, after discussing this with kernel/KVM developers, there are = valid >>> debugging scenarios (e.g. KGDB or guest debugging via KVM/QEMU) where e= xposing >>> `POR_EL0`, `POR_EL1`, and `POR_EL2` simultaneously would be useful. Thi= s seems >>> like a broader GDB register naming issue rather than something specific= to >>> FEAT_S1POE. >> And Marc Zyngier too: >>=20 >>> It would certainly make our life easier if GDB was in general adopting >>> the architecture nomenclature. >>> >>> It is probably fine to have a "shorthand" such as POR for POR_EL0, but >>> I'd like to make sure that it is possible to unambiguously target the >>> correct register for the cases where we have to debug a full guest >>> (which is something people actively do using the QEMU GDB stubs). >> So as Marc says perhaps we could have an alias por for por_el0, like we >> have lr for x30, or (in the other direction) x31 for sp? >>=20 > > Naming registers after their architectural names is fine as long as they'= re really exposed > as their architectural selves. Sometimes we don't get exposed purely arch= itectural > registers via ptrace, so it would be a bit confusing to do that. Ah, now I got it. Yes, I agree. > If we have plans to support QEMU bare metal, using the architectural name= also makes > sense. Agreed. >>>> diff --git a/gdb/features/aarch64-poe.c b/gdb/features/aarch64-poe.c >>>> new file mode 100644 >>>> index 00000000000..4bd795e9fe6 >>>> --- /dev/null >>>> +++ b/gdb/features/aarch64-poe.c >>>> @@ -0,0 +1,68 @@ >>>> +/* THIS FILE IS GENERATED. -*- buffer-read-only: t -*- vi:set ro: >>>> + Original: aarch64-poe.xml */ >>>> + >>>> +#include "gdbsupport/tdesc.h" >>>> + >>>> +static int >>>> +create_feature_aarch64_poe (struct target_desc *result, long regnum) >>>> +{ >>>> + struct tdesc_feature *feature; >>>> + >>>> + feature =3D tdesc_create_feature (result, "org.gnu.gdb.aarch64.poe"= ); >>>> + tdesc_type_with_fields *type_with_fields; >>>> + type_with_fields =3D tdesc_create_enum (feature, "por_el0_fmt", 4); >>>> + tdesc_add_enum_value (type_with_fields, 0, "---"); >>>> + tdesc_add_enum_value (type_with_fields, 1, "r--"); >>>> + tdesc_add_enum_value (type_with_fields, 2, "--x"); >>>> + tdesc_add_enum_value (type_with_fields, 3, "r-x"); >>>> + tdesc_add_enum_value (type_with_fields, 4, "-w-"); >>>> + tdesc_add_enum_value (type_with_fields, 5, "rw-"); >>>> + tdesc_add_enum_value (type_with_fields, 6, "-wx"); >>>> + tdesc_add_enum_value (type_with_fields, 7, "rwx"); >>>> + tdesc_add_enum_value (type_with_fields, 8, "???"); >>>> + tdesc_add_enum_value (type_with_fields, 9, "???"); >>>> + tdesc_add_enum_value (type_with_fields, 10, "???"); >>>> + tdesc_add_enum_value (type_with_fields, 11, "???"); >>>> + tdesc_add_enum_value (type_with_fields, 12, "???"); >>>> + tdesc_add_enum_value (type_with_fields, 13, "???"); >>>> + tdesc_add_enum_value (type_with_fields, 14, "???"); >>>> + tdesc_add_enum_value (type_with_fields, 15, "???"); >>> >>> I'm not a fan of this. Have we considered alternatives like pseudo-regi= sters that map >>> to/from the raw POR value? >>> >>> It feels like this is working around a gdb deficiency of not having a p= roper type, and >>> the >>> right way to solve this would be extending gdb in some way. >>> >>> With a pseudo-register all of this would be interiorized in gdb, and we= would be left >>> with >>> only the raw POR value of 64 bits. >>> >>>> + >>>> + type_with_fields =3D tdesc_create_flags (feature, "por_el0_flags", = 8); >>>> + tdesc_type *field_type; >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P15", 60, 63, field_ty= pe); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P14", 56, 59, field_ty= pe); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P13", 52, 55, field_ty= pe); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P12", 48, 51, field_ty= pe); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P11", 44, 47, field_ty= pe); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P10", 40, 43, field_ty= pe); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P9", 36, 39, field_typ= e); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P8", 32, 35, field_typ= e); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P7", 28, 31, field_typ= e); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P6", 24, 27, field_typ= e); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P5", 20, 23, field_typ= e); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P4", 16, 19, field_typ= e); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P3", 12, 15, field_typ= e); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P2", 8, 11, field_type= ); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P1", 4, 7, field_type); >>>> + field_type =3D tdesc_named_type (feature, "por_el0_fmt"); >>>> + tdesc_add_typed_bitfield (type_with_fields, "P0", 0, 3, field_type); >>> >>> Likewise for the above. This is hardcoding the interpretation of the in= dividual bitfields >>> into the XML. >>> >>> Maybe Thiago has a different opinion here. >> The interpretation is fixed by the architecture, so hardcoding it makes >> sense IMHO. But I don't feel strongly about this. >>=20 > > Sorry, I wasn=C2=B4t clear in my comment. The interpretation of the bits = is dictated by the > architecture, but does it also require us to expose the raw register as a= segmented view > with withP<0-15> entries? > > The last part seems more like a visualization aid to me, and that could b= e handled > internally by gdb instead of via XML. Ah, understood. Now (and having read your other email) I see what you mean with using pseudo-registers. Indeed having pseudo-registers to access individual protection keys sounds like a good idea if we expcet users to want to do that. --=20 Thiago (he/him)