From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QV/1Bt1nZGoUhSwAWB0awg (envelope-from ) for ; Sat, 25 Jul 2026 03:38:05 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=MWXKScpU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 168CF1E099; Sat, 25 Jul 2026 03:38:05 -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,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable 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 76D011E099 for ; Sat, 25 Jul 2026 03:38:04 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 88C944BA2E3C for ; Sat, 25 Jul 2026 07:38:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88C944BA2E3C Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=MWXKScpU Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 7DCAE4BA2E2F for ; Sat, 25 Jul 2026 07:37:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DCAE4BA2E2F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7DCAE4BA2E2F Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::435 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784965058; cv=none; b=BrHZC6YSlgDBPSaP61wPsQTbl2+apIL/Olca/A6cYk8L37YQOG7iMD7lJMCvuKz7Qyt/+VAxWBBMqi0VX5u+v2RO6Q7dnaiqaAxTrzWj8jhhOV7Uxx0Xz5BAabsV9EBHSc/bA/mSNX3+XUVth62GbsEU5xgMc57obErn/6NATGg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784965058; c=relaxed/simple; bh=RsScsr7ZigV2Y+w+bKUN4/LOEArU13WwmW+YN4E+U0A=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=B+gCBRMekGf2zW19LuL5u3eRXQkO2CymByyoG8yt1op9Sc3GhKwFZ5rQS7cAIP6w1dolw0MdbO1mn/rKYqLljI92GYU2LxboI9jFWHJBnB+sl6o3I8bmAbTuzDtTV8fg6ykcEyqc6TILsJ3CtmjWozaPgD9jH0vnSnwudR12JgA= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=MWXKScpU DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7DCAE4BA2E2F Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-47f84023916so1105555f8f.3 for ; Sat, 25 Jul 2026 00:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784965057; x=1785569857; darn=sourceware.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=dQZ3fxY2fH3CO80yP7cM3NQIpGjHeJtvOUwfu73uiqY=; b=MWXKScpU6ns66BKfjqrz0gFQVDv9LBxbFh955RCPn8WXioj76hgr4Uq+zZvihvx7xs xeodnPX3Q+h7E+bY2JL40KUbvIzXteShk4y+d2yf67MmRPIarDq/XxnwvR7z+6A2EJ4w qxqNAKja6itBFXgeVtWPlynhcy4LoXodOUi1AC78j8XQE/ud02mfG0+/b44bx+cYNmzu Q31hwdNhMQ9qAyJNnONL8ZylKJYAIbzH5gPM+O5ZM8Mz3JH03fXnlMmgmh2sLCAp+zaE xMwBck/a7vp4muRcpNc0PLf+4wNHvBhQkX7DBAmB0osMAyBEWmxLnYfcfvS+A0tMDDoe bmvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784965057; x=1785569857; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dQZ3fxY2fH3CO80yP7cM3NQIpGjHeJtvOUwfu73uiqY=; b=BtKd5eIT8Ogzk/yPY5c46DdOwAcZ1ShRUK+rHB9or9ogMvbulcyzYYbJT2aebgrvyp giiT8AUczK/+Q0kC0ApLbBOrxCft+MEkeFerEuVEJRsMvk/CG1I6jjVOhIeYLCqDZ1TE loZj8Ot0kUj/QVhFmo4sj6NVsRTBQa1yUsenMpuCx6VdGY4KFUrgT+1Niwbzy4cjWmiI D4RcLA4vg7iqrUl3AUhcLsKn+ORC2lLrC5VYka73uougduJpjRbpI2HbuoS0WndSbR4V xhqpNjGy5oL9weFN5+OR6VGMmTNL2uyHDdHIHMH1kXdYlC4YaE47lMBsPID8S/9xLzf1 BbVQ== X-Forwarded-Encrypted: i=1; AHgh+Rq0sesLq5WcmP6r/mwc3qT/9L0D+2vZLGeg1ALSysIjHoDyFGupRgfweeM7jOLVXgzCmc3Tp6slWdie0g==@sourceware.org X-Gm-Message-State: AOJu0YwZE647DZihpWs2mUS48Le8+sZd7CevMbFeER9RkbsEYLX3PUqR eKe6qKT6VRoR12Cu7dWpa4WbTBcKrmAyV1fuHiY7z3Sx6LVLKkplR7GH X-Gm-Gg: AR+sD10+D8ph4PfbJsk2z0XljxV+sujzsn1f4+DrqA9IFdISZhsDfQI4oc58iCoPuai w6b5VpmQPpLbS3HNZRK+ifKELehXBsNW9qWV23Zf2QEuLmdzI4ESPt7vmsyCUrcO0mSkdnOCfXP lOd+6cEwS+SPOy1cDbfGcFvi7LBsfxOtshY3eT0tY/LFOdsbmMYWSzk2PJplY28IBFrbH/GxKhw CkXQrJQA0B0WxhHTJUM/lr83i87jvyGYh0S1XxDym8PtGw1QupHHO0Yh19fn2DVx7D9D/9hFEcB T20kzXKn+aj79ZMedruAPTziajrL74Z/NrNlL9fFvYuFjbg8yhsx50E94Kid3CWNOdbepxp21zw wgxDUnV36Y/0aEnelV6f+iMvfYN6rxp5Pz3gCrJVOHj382zZdfWCm1B86gdfz+V7yTc/vcZfyea mQvH8g2/VaOT13q7C6/olAEQASrw== X-Received: by 2002:a05:6000:613:b0:47f:903a:5eea with SMTP id ffacd0b85a97d-47f9fc89cf5mr1431804f8f.4.1784965057023; Sat, 25 Jul 2026 00:37:37 -0700 (PDT) Received: from [192.168.0.38] ([86.12.216.189]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85bdac28sm29196256f8f.16.2026.07.25.00.37.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Jul 2026 00:37:36 -0700 (PDT) Message-ID: Date: Sat, 25 Jul 2026 08:37:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/5] [PATCH 1/5] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE Content-Language: en-US To: Thiago Jung Bauermann 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 References: <20260714201530.78374-1-srinath.parvathaneni@arm.com> <20260714201530.78374-2-srinath.parvathaneni@arm.com> <87bjbvlhey.fsf@linaro.org> From: Luis In-Reply-To: <87bjbvlhey.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 On 25/07/2026 07:20, Thiago Jung Bauermann wrote: > 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? > 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 architectural registers via ptrace, so it would be a bit confusing to do that. If we have plans to support QEMU bare metal, using the architectural name also makes sense. >>> 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. > Sorry, I wasn´t 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 be handled internally by gdb instead of via XML.