From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wQj5BrRVZGqzbSwAWB0awg (envelope-from ) for ; Sat, 25 Jul 2026 02:20:36 -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=mDfIjs0l; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 186491E09E; Sat, 25 Jul 2026 02:20:36 -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 77CBC1E099 for ; Sat, 25 Jul 2026 02:20:35 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 139554BA7983 for ; Sat, 25 Jul 2026 06:20:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 139554BA7983 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=mDfIjs0l Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 8B7494BA5436 for ; Sat, 25 Jul 2026 06:20:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B7494BA5436 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 8B7494BA5436 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::52a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784960409; cv=none; b=UzNjaYm0Tgj0pF20kj3dht1pJsJLfaAQnt3gHHR7wIOTvJa31IzhY4A0MRAoRKGaLH/YZVIIfJKD+pQtGjmwpfZkGl46qD6EM2q4xDQlfZXMPAcr0GkOKfxMIoQW31T7KUmk08vm63U2/WO3rILoFk46vxuQZvKerzJ8/HVnDQ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784960409; c=relaxed/simple; bh=bNoiL4HLe1q8/o/01iZNSAxkf4AGyfQawFx8/LBtSw0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=tCydlpj2zxv7P6Ui0hbKQioYaim4IteoTgGi/xuk3so82tP/5qVVM3iijWCKryds58KL3CJV/S/p1OFcmI01XP/F+/0/C7fFQWb+Z/jufKj2oGE6msjxU8SJz9Nhd00bAUzDHlPAzmwk8cnrBpklfCGskchwRipCftYt9xLqVxo= 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=mDfIjs0l DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8B7494BA5436 Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-cbb973e6749so1324933a12.1 for ; Fri, 24 Jul 2026 23:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784960408; x=1785565208; 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=pZdZtYs60zR96BGsVFWJurEQA71uiLY1rMZnjNIfCSE=; b=mDfIjs0lLAZgSUpFzpMcY5O18uq9ER54nbLTZ/b5s0ffs99J0oxP5im7RY0Q43DDWo ODAQn85vzYQeIpHQ+xatWvKZNwMIG5R7UVjQLEB87Ep3GQAZebEkGDnYjTNw1o26GA1M 6OcZAOL1IeA8dKuci9rVXfWswKInQzyzO4RwTEczvG7JVGpJakee9JQdeZlxzo8qzrdN 3IkF/RdR4LkHsfQ4YIcGj+5ZuWNW3TAG9KqYuDfljyfIYD1j0tcVAU63cW1LnjfypZNq V470st0gEHeT7Yzvv6AAHyZtsj3rVGuv9Z146ffMSJWOPZtVP/YCkZmgtClE4zsSaqj3 /5dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784960408; x=1785565208; 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=pZdZtYs60zR96BGsVFWJurEQA71uiLY1rMZnjNIfCSE=; b=H/bA1CBlChEH3wF0aiAuU9zj/Z+gRyd14HXvXBXaRKQOX/rAQWfXPUIHf7tCIjwNfC 9+3fz0ntFBoF+ILpTQARIEvEdl49ze+IGFTEcztEx9d4GqgFd438m7Ed9P/eJnMmouyB hWrg9l5g4SIbD7hv2CRxKWVpO9NA4SCepW2+btg3uBFRryp0j5Hv7qZSBgOkcRMc9Vgc NcuMztrCfQaLwn01i/dvKpNkgrHPQ/Uvk7wL2VRlTUxxANy4ppcfXS7XzkUuDaQIx9AG IioSurD8vSiqYX9HQxiQDgSIJ1d6NnzUL4JuJ6VkDXiCounctrBjrWyfXVEO7GsYr0VP dSqA== X-Forwarded-Encrypted: i=1; AHgh+RqKrX776GRYxBzx0dgY1Lo7AnDt0LDmPKvxFbS/AMKzV4iRYFyw0l7e1eCiUOACZAIAjCD4gPY7s9Z34w==@sourceware.org X-Gm-Message-State: AOJu0Yyz96Pf+rbZWQLQUO89G6eTKm8m+Ca86yzhItO0BxQ/jBT/QYwu hiIyV/tiiFYmEdAyGSuU9P7gM+gEwSP1RbGshX6Pg9g343iweOdvumPCCyc9L6qIoes= X-Gm-Gg: AR+sD123h4BYTbiFLCrwg1UupHByoaY4W2yUvaXwRbZadfwjzuvDb4knrplzJVqWg54 sWKcENYOx9RN7k9V4oFbxp108ydPJV7B+YVh3YxNtwC7i3FJ9mdETkReqNOKBAx3vYHJoO82ynX HRjlWRVsbty4g/vgZwSHER28xK3rI0q/Mf0OwtehqOXI9xKKLc4/WIHBsLIKzZt5JxFvpakhrBT OX35oAcX8S42gQfCCi+FvCmk2aPiiFc2uzTSxpEJDH+H+V5YIAqY6qOR/u/the5syr6jSMRBuQ7 ygjRrx48psUsiBo9IWlYKFxuf03WhGZVV0VbKvkaLUkioDImbtFXnZw6oZYgYrVgEtKhCf2u0Jn YcGO8CAcOgpnatvdUf7V6dBPtBlSR1Jqoz1Zz4trVd3dZrHQ9OgP1uOXWLjHk3MwuCgPJEZ3p50 RY/JTyxbap6cR3 X-Received: by 2002:a05:6a21:6007:b0:3b3:223f:d3fc with SMTP id adf61e73a8af0-3c67df10d40mr1303989637.45.1784960408281; Fri, 24 Jul 2026 23:20:08 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-314bc548f5dsm7427673eec.17.2026.07.24.23.20.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 23:20:07 -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 "Tue, 21 Jul 2026 20:53:29 +0100") References: <20260714201530.78374-1-srinath.parvathaneni@arm.com> <20260714201530.78374-2-srinath.parvathaneni@arm.com> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Sat, 25 Jul 2026 06:20:05 +0000 Message-ID: <87bjbvlhey.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 Luis writes: > 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 userspace 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: > That said, after discussing this with kernel/KVM developers, there are valid > debugging scenarios (e.g. KGDB or guest debugging via KVM/QEMU) where exposing > `POR_EL0`, `POR_EL1`, and `POR_EL2` simultaneously would be useful. This seems > like a broader GDB register naming issue rather than something specific to > FEAT_S1POE. And Marc Zyngier too: > 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? >> 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 = tdesc_create_feature (result, "org.gnu.gdb.aarch64.poe"); >> + tdesc_type_with_fields *type_with_fields; >> + type_with_fields = 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-registers that map > to/from the raw POR value? > > It feels like this is working around a gdb deficiency of not having a proper 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 = tdesc_create_flags (feature, "por_el0_flags", 8); >> + tdesc_type *field_type; >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P15", 60, 63, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P14", 56, 59, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P13", 52, 55, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P12", 48, 51, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P11", 44, 47, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P10", 40, 43, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P9", 36, 39, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P8", 32, 35, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P7", 28, 31, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P6", 24, 27, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P5", 20, 23, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P4", 16, 19, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P3", 12, 15, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P2", 8, 11, field_type); >> + field_type = tdesc_named_type (feature, "por_el0_fmt"); >> + tdesc_add_typed_bitfield (type_with_fields, "P1", 4, 7, field_type); >> + field_type = 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 individual 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. -- Thiago (he/him)