From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ScjfECBNQmr0Zx0AWB0awg (envelope-from ) for ; Mon, 29 Jun 2026 06:46:56 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=CCyoCbZf; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=CCyoCbZf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1E9491E098; Mon, 29 Jun 2026 06:46:56 -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,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham 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 B49C11E024 for ; Mon, 29 Jun 2026 06:46:53 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B85A4BA2E33 for ; Mon, 29 Jun 2026 10:46:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B85A4BA2E33 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=CCyoCbZf; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=CCyoCbZf Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazlp170130007.outbound.protection.outlook.com [IPv6:2a01:111:f403:c202::7]) by sourceware.org (Postfix) with ESMTPS id B1A954BA2E2A for ; Mon, 29 Jun 2026 10:45:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B1A954BA2E2A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B1A954BA2E2A Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c202::7 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1782729942; cv=pass; b=yA9DwqOdg8zX3ZLCbhMqvxKVrHbfgKjrBXr54kCiBe0yD+r6pN4wsmihf5P3tDYm9Aep+/MGBhpcQPCHQY5TqmohHox/Ct2WkIOr7UIVFZFfrTD94RevXmJOoGhc2uQKjxo6IHl4YGtnButipgDd2naj7QgsrkodsKfEkjC8bmI= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1782729942; c=relaxed/simple; bh=PhzLsWleFBQFkqfBoKxfRPt0xAuUJEPkO9JqxAOawf8=; h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID: MIME-Version; b=Gc/LiZP/CSM1VLdN4UTMCHQJZzf9TEHW2OKu8kOCc2MCi8D/hbXsYQiXiWedbB3aX+UpZVdxv0i8z7evIEbb6qiErQaMncn+6lqRN0zEsknwWl18bdbuFE4JyMTXzuLC8iJ0pmtmuJGhc3lY5pOFW5DF37os2/xhZAMio/dNeUk= ARC-Authentication-Results: i=3; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=CCyoCbZf; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=CCyoCbZf DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1A954BA2E2A ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=Bz1IzpQTVXvmLj9XJN+5UMWtye/OP2s6OxM4tLqb+MRkRSStXCjvp235HtUG4GmpbOlny6x1Vmkul4YE+QRpm6vPVGjLorzYVsQAjJulPbvyX9uSxGVTBBbWLyvTyNn+msScBJ+D5mWZn6eAu23vAqB2EOtBrQIrLtENxtzDsDnUjDe7LWxuSM60M0tKd6AqS1qus1D+KMVMM8kkf0mvno+xUyGnceDhp86zsC5iIMCprakpzT01L2No7mWJCzyNu5n1/xN9tn82J0KTKhucL2ZQsz7U6CqjWceR033itDeaIeoHQUMLFd+qkhT4vqtTh6Dk2vdA3+Q5Sq+n5Cqs1A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8JWe2rA/qxWnLA/e+jp/EtrhHbmvlWEzec1gg/y8fFk=; b=DhY7zuuQNV1Dj0mIje/RcH6dVdmrTUg71j3qpFnPfrKojpCZzFVFyTHs1klmK4OjKE+3HD91W1M1UAPwbOurjimoA83mUy0kd875jsPauqKZVXaejBDFdTpynUZGH38mvnDzCo+UGBAOQ48svXDeWzJq625LBkbO626VF8q8ghiIHNJSTsr1FWXZHwJVO4cP3YKvLQFzzQT0yRE32iq0Rs3lPyCHnwizlgoSMUHZUAgL2G9U2mZEIiup5vpqNNJMguz29n/DrdFKmzlW6PkZX11F/REzOBhZZsxTAp0LgdRkwxINKXb5WuDDPh4M7pB9ZRYJkVrtCXmBVT2N0MnHIw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8JWe2rA/qxWnLA/e+jp/EtrhHbmvlWEzec1gg/y8fFk=; b=CCyoCbZfosu6q2ZWfOF13H8qSi/KjeuoIZ91TMSW4W0yykd7B/tzQxghU2pfARZKM5yAdv4OHnIIj6XFM4LW1nnL12knfN0K1yYBFIoEVsvhjNkFB7oKzdd3RTGXCSgLJkguLm15E9p//Iy/KepxDg3oWM0hd0vD6qhBHQfXn+0= Received: from DU7PR01CA0021.eurprd01.prod.exchangelabs.com (2603:10a6:10:50f::9) by DB5PR08MB10164.eurprd08.prod.outlook.com (2603:10a6:10:4a1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.159.19; Mon, 29 Jun 2026 10:45:34 +0000 Received: from DU2PEPF0001E9BF.eurprd03.prod.outlook.com (2603:10a6:10:50f:cafe::43) by DU7PR01CA0021.outlook.office365.com (2603:10a6:10:50f::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.159.19 via Frontend Transport; Mon, 29 Jun 2026 10:45:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU2PEPF0001E9BF.mail.protection.outlook.com (10.167.8.68) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.181.6 via Frontend Transport; Mon, 29 Jun 2026 10:45:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rbufHz1elDX4ewoDV6PqYEdHDvv2YfCz0oity0Bn2k071d4xef06mr4/XeFvvJKacmFElWqWSAor2y3qV1RQCpr/+u+fUSUX0/RmWWbW+IH9V92vvy+nM9XPjKvocnDGfCjfD3KHFooQWhg6DVb97PYEanSt5XdPkFDs1FoHESgqIyaiwnj3o+ZAi9a8UB7VMju28qqz2AeAptqCmqb0EDks5JmWGuGgL4OBIggem20WjYiBR7Nq9DUfPWaFGM64gS5eHoBznFlKANGi83qY/PFcMVmj4Ujy0S5W5V6ABgwsBiKiQMViZ+pyKCU3qSjWDV+xZDEM6hJZ8ZFD23vrUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8JWe2rA/qxWnLA/e+jp/EtrhHbmvlWEzec1gg/y8fFk=; b=pmUev3j9W2zDOAdst58bnVJdaRPbnRZvjSEfBkgwuaDTCKbDh77vGfPkVY4I1oRoecj/ypH09Ie4C0POmsvd3ezbUw1oqxWDtTjz0xwUtRYEUSHSTDAQTDvDMto5+rlXF0LCI8FmHtOCxoEvYfEhgUfdbQ6yfH2lHrpf4tXRIRuTWNKRMVPfTJrWbKhaEkFf51vcAZGmnhb6HDvOp2WS+H61lxE8dB+349bVEyspABVRNcabuIPeEWWF2jr2DmU1O57EcFnO2p1qjq5fZ0YBK7GyHPo3MjhVH5WsgQWWpMKHj2gca6kE1vbRthWhX0Qy1BK/sWiIHA/I85yIcebhsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8JWe2rA/qxWnLA/e+jp/EtrhHbmvlWEzec1gg/y8fFk=; b=CCyoCbZfosu6q2ZWfOF13H8qSi/KjeuoIZ91TMSW4W0yykd7B/tzQxghU2pfARZKM5yAdv4OHnIIj6XFM4LW1nnL12knfN0K1yYBFIoEVsvhjNkFB7oKzdd3RTGXCSgLJkguLm15E9p//Iy/KepxDg3oWM0hd0vD6qhBHQfXn+0= Received: from AS8PR08MB10099.eurprd08.prod.outlook.com (2603:10a6:20b:628::5) by PAWPR08MB9008.eurprd08.prod.outlook.com (2603:10a6:102:341::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.159.17; Mon, 29 Jun 2026 10:44:27 +0000 Received: from AS8PR08MB10099.eurprd08.prod.outlook.com ([fe80::21b3:9dda:5250:40c1]) by AS8PR08MB10099.eurprd08.prod.outlook.com ([fe80::21b3:9dda:5250:40c1%6]) with mapi id 15.21.0159.018; Mon, 29 Jun 2026 10:44:27 +0000 From: Srinath Parvathaneni To: Thiago Jung Bauermann CC: "gdb-patches@sourceware.org" , "luis.machado.foss@gmail.com" , "guinevere@redhat.com" , Ezra Sitorus , Matthieu Longo , Mark Rutland , "maz@kernel.org" Subject: Re: [PATCH v2 1/7] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE Thread-Topic: [PATCH v2 1/7] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE Thread-Index: AQHdBZbPh/en436Qo0W1fh8Pu2phwbZR6xongANxCPg= Date: Mon, 29 Jun 2026 10:44:27 +0000 Message-ID: References: <20260626180821.376406-1-srinath.parvathaneni@arm.com> <20260626180821.376406-2-srinath.parvathaneni@arm.com> <87a4sgikk4.fsf@linaro.org> In-Reply-To: <87a4sgikk4.fsf@linaro.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: AS8PR08MB10099:EE_|PAWPR08MB9008:EE_|DU2PEPF0001E9BF:EE_|DB5PR08MB10164:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f308672-b9f2-43e3-9f4e-08ded5cb8c0f x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; ARA:13230040|1800799024|366016|23010399003|376014|6133799003|22082099003|18002099003|4143699003|56012099006|5023799004|11063799006|8096899003|13003099007|38070700021; X-Microsoft-Antispam-Message-Info-Original: Qj7n6J8X8NSC+5+3OZG+yuFptNjNodhZrQ95umJA38ZoN102m0mgUwJTgSciv2TQHnIjuMqKwV4KUyPmynF65+8RHQAl4jQ45cXiFSy/TLmcWRQN9gPRgBn36pB1XF/uz5JTsb7+vaD8bl9ZbyeMDkoHF3ndaU4p8uZOEFQR5sqQNNlM7slns7beYYRbqbXiOz2boAvw8jJ5YISHalhTtxzE3DEGqGfbzOLOZkDQSduHsndaPhVVYtB0R3kGDWc1DoVKMNaFvcbfE/Jv/SWpaOLN1joz1G0DCXix01ILKP7sYwKsCrjHYu2pKkAi7qOGdf9FAkyIViz7HVE321i4FQgj7cE0clsapzgTZDLxunDgzj86EjvB1gGwNLmt6bBhz2mcIV+CZtg0Zgl8GHxgpvByWg6hX3bQN/+/1+QArWJFpXIUgKEtqhEmFHeAw4FoPMQenJV3tJuVfACjRPJu+9ORxMhXC2XasJWXEiDaBgIzVTdmiGN9XFqHZh40cLoh3gjA1LMYIT9xb2Xwk33p/pd7R0eoltzQOujwlm28gJu410KrWH145vb1fVIXA9cEwKHUjwu/uhhJUd8/BLYBcKZB8CdHtuQ1/Xsbdw2zvn6ooJr1wW42QjP/7W0ejdDzFrPkpjwc0WKQCWLhPvWLkvjQt2zsVGvPpULYFWhB3MNnRorFvqJzjsBQn6iW7NwpNatYRLOVZOnHLU8kvMsiNYk4b4ktWZKxLS5s2Ps5pOA= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR08MB10099.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(6133799003)(22082099003)(18002099003)(4143699003)(56012099006)(5023799004)(11063799006)(8096899003)(13003099007)(38070700021); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_AS8PR08MB100995E349C5BFAF1F5A4BCAC9BE82AS8PR08MB10099eu_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: L8cKuJGFcxVSXaSzZSWMQVeGknFGmpNQNFqkwyVXG3aqzDPqAsd7B0pnRbErqi5MEQaiuYLCmjOHkbhmc4qrEhLrailEWckRPP1/em4OqYLtQm0gfeDRdNX0Jx0culBux2rBiS6lHwix3P09ppQ4LAJFZdcoYlKpWT3DUHYj7Q2GZE097XtE14+NHHPgS7hcSZR1y+3uvgarHRnX0wOEK6oOkDrGPuvP6XBl1Wk6t+cPhmQ8qPsaRNATsuErmwX17lpg5dlLERVLPnrrWt4qYoR2k2o7KDZvc2GaAz6CdvhZb87SoDIS4JAsO8APHAbWjyXAM0YnaZXw/eiaL6pxsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB9008 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF0001E9BF.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 99034a59-bf8c-40c8-a9b2-08ded5cb6484 X-Microsoft-Antispam: BCL:0; ARA:13230040|376014|82310400026|1800799024|36860700016|35042699022|23010399003|14060799003|6133799003|5023799004|4143699003|11063799006|22082099003|18002099003|56012099006|8096899003|13003099007; X-Microsoft-Antispam-Message-Info: 73M4FjKUoE3ZMJD7V0zopgP1Q93jT9PDJfYwzJpZLwcfGjSXMLqfYwVy/s/2NTGGQdSGt8KFrUKifcc2jh9f6v8+/6O1jntm8z7YtejtlwXpdOZkKr9+K+jfIIf3YTQSjIjYpwQQyqGftERqNSrq46BBxWW1t3ffiKM0OPBg/aRhLP3HxaorDia4PONxuFfsDnaOkAXAatxE0Po6mHMFTnKECUhgRBbo6uvTOcpztmKKFSfDz1LldAp/GLmOavhx6NBj/Z6ZsmmNaNNN5UqN/6bmde5eamtMx41Zz23JbVSrk2FVjuiY3fZDk5VDbua74X/6XFez7u2bqY+5ccaCszF/m0tCQbHC4QaUPXRIaEKe3rxeggo9n+dUkAXzvbFAtvihITaweUASjvCQAB193NMYj51euu+BAW3TkZCsXsmKSwrbc4mQItmiszTDqb1z++wPrU6yhAJ8gX1OJ2w5mAtziUjRVqavpzy8lrg+cJC873Ru3u5f7t3v8YIm7P2bgP1+jqC2qfcrve4m5KEIiFQ8YlwzUtiDkJezVv3g/M20cfniKFL+bFgKOq+QB1RHkKvCGw+GbnDU6Jp5Haf/vYfjiqPopkqgvCfdx8D5HhtGNce/wfWuPkUEi5VtVhFh58Nre8GJYLL/2b/rN212I5FIE9H/7Rc/mJCSVA/j41Oa5cMle3qF0MlqEr/wRvjL27C+13HO2H3j/qtBWax1yw== X-Forefront-Antispam-Report: CIP:4.158.2.129; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:outbound-uk1.az.dlp.m.darktrace.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(376014)(82310400026)(1800799024)(36860700016)(35042699022)(23010399003)(14060799003)(6133799003)(5023799004)(4143699003)(11063799006)(22082099003)(18002099003)(56012099006)(8096899003)(13003099007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 0Gyyrf/V3S2w+S+cGoxSmkuZIwnrV+h1Y3qaXNeETAPz2RsULzjDfoK9hI4cARwr7QebL5FJiLl8EzbqVC0IioMwMiQg3/2Xy9NODvHJmBEDITfNcccBCK0xKoeBbDYG808HhO7xhxpQmj2hSzvqoDrvAFLtcyXgYEafdWc8wbHF6F5M9l1VJQjjAruo4QI5KyI7HB8x/WVYpdHJCksXJZdy/oP/39ff/H+BZfaoy4Yd2dQWhAWrFbX7HyvwA7hTMx3DKT4B5GN8f4WwwwhiWKEtnPumrzWbeocxSs69TwKsG6/yYOulIf86WQA+ZGD7j+FvvLAj/9r4SgHIKyR3bunmRm6onxEtlXepIck16+3kzQhO3Ygqtg8SXg1u4KfWagM6PgAy6sdnkHNaLx5RKwgFYYgIFi6n01JlLTh0eOLR+Ied2/5X6CPa1hcTnaR4 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2026 10:45:33.6975 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4f308672-b9f2-43e3-9f4e-08ded5cb8c0f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[4.158.2.129]; Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF0001E9BF.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10164 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 --_000_AS8PR08MB100995E349C5BFAF1F5A4BCAC9BE82AS8PR08MB10099eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >> * info registers por_el0 >> * p $por_el0 >> * p/x $por_el0 >> * set $por_el0 =3D > >One question, more about general policy on the AArch64 GDB port: > >Should the register name have the _el0 suffix? It's more than half of >the register name (though tab completion helps). > >We don't currently have that suffix in the name of any register. And in >the case of Guarded Control Stack, I didn't add it. For native >debugging, it will always be the register at EL0. For remote debugging, >I assumed the target would send the register corresponding to the >current exception level in the inferior. > >Can there be a situation where it would be possible to see both the EL0 >and EL1 (for example) registers at the same time? Or a situation where >the inferior is at EL1 but one wants to see the register at EL0, or >vice-versa? > Thanks Thiago for the review. I'll address the other review comments and post a new version of the patches. I'm happy to follow the existing AArch64 GDB convention and expose the regi= ster as `POR` for consistency. That said, after discussing this with kernel/KVM developers, there are vali= d debugging scenarios (e.g. KGDB or guest debugging via KVM/QEMU) where expos= ing `POR_EL0`, `POR_EL1`, and `POR_EL2` simultaneously would be useful. This se= ems like a broader GDB register naming issue rather than something specific to FEAT_S1POE. CC'ing Mark Rutland and Marc Zyngier, who can provide more context on those use cases. Regards, Srinath ________________________________ From: Thiago Jung Bauermann Sent: 27 June 2026 07:06 To: Srinath Parvathaneni Cc: gdb-patches@sourceware.org ; luis.machado.f= oss@gmail.com ; guinevere@redhat.com ; Ezra Sitorus ; Matthieu Longo Subject: Re: [PATCH v2 1/7] gdb/aarch64: Add POR_EL0 register support for F= EAT_S1POE Hello Srinath, writes: > 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. > > With this change, POR_EL0 is available through: > * info registers > * info registers por_el0 > * p $por_el0 > * p/x $por_el0 > * set $por_el0 =3D One question, more about general policy on the AArch64 GDB port: Should the register name have the _el0 suffix? It's more than half of the register name (though tab completion helps). We don't currently have that suffix in the name of any register. And in the case of Guarded Control Stack, I didn't add it. For native debugging, it will always be the register at EL0. For remote debugging, I assumed the target would send the register corresponding to the current exception level in the inferior. Can there be a situation where it would be possible to see both the EL0 and EL1 (for example) registers at the same time? Or a situation where the inferior is at EL1 but one wants to see the register at EL0, or vice-versa? > --- > gdb/Makefile.in | 2 ++ > gdb/aarch64-linux-nat.c | 66 ++++++++++++++++++++++++++++++++++++ > gdb/aarch64-linux-tdep.c | 1 + > gdb/aarch64-tdep.c | 18 ++++++++++ > gdb/aarch64-tdep.h | 11 +++++- > gdb/arch/aarch64-poe-linux.h | 29 ++++++++++++++++ > gdb/arch/aarch64.c | 4 +++ > gdb/arch/aarch64.h | 7 +++- > gdb/features/Makefile | 1 + > gdb/features/aarch64-poe.c | 14 ++++++++ > gdb/features/aarch64-poe.xml | 12 +++++++ > gdb/nat/aarch64-poe-linux.h | 28 +++++++++++++++ > include/elf/common.h | 2 ++ > 13 files changed, 193 insertions(+), 2 deletions(-) > create mode 100644 gdb/arch/aarch64-poe-linux.h > create mode 100644 gdb/features/aarch64-poe.c > create mode 100644 gdb/features/aarch64-poe.xml > create mode 100644 gdb/nat/aarch64-poe-linux.h > > diff --git a/gdb/Makefile.in b/gdb/Makefile.in > index 57f384170ab..3dc9cd07dcb 100644 > --- a/gdb/Makefile.in > +++ b/gdb/Makefile.in > @@ -1292,6 +1292,7 @@ HFILES_NO_SRCDIR =3D \ > arch/aarch32.h \ > arch/aarch64-fpmr-linux.h \ > arch/aarch64-gcs-linux.h \ > + arch/aarch64-poe-linux.h \ > arch/aarch64.h \ > arch/aarch64-insn.h \ > arch/aarch64-mte.h \ > @@ -1540,6 +1541,7 @@ HFILES_NO_SRCDIR =3D \ > namespace.h \ > nat/aarch64-fpmr-linux.h \ > nat/aarch64-gcs-linux.h \ > + nat/aarch64-poe-linux.h \ > nat/aarch64-hw-point.h \ > nat/aarch64-linux.h \ > nat/aarch64-linux-hw-point.h \ > diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c > index 52ace4aab41..54265920d69 100644 > --- a/gdb/aarch64-linux-nat.c > +++ b/gdb/aarch64-linux-nat.c > @@ -34,6 +34,7 @@ > #include "arch/arm.h" > #include "nat/aarch64-fpmr-linux.h" > #include "nat/aarch64-gcs-linux.h" > +#include "nat/aarch64-poe-linux.h" > #include "nat/aarch64-linux.h" > #include "nat/aarch64-linux-hw-point.h" > #include "nat/aarch64-mte-linux-ptrace.h" > @@ -569,6 +570,54 @@ fetch_gcsregs_from_thread (regcache *regcache) > &user_gcs.features_locked); > } > > +/* Fill GDB's register array with the POE register value from the curren= t > + thread. */ > + > +static void > +fetch_poeregs_from_thread (regcache *regcache) > +{ > + aarch64_gdbarch_tdep *tdep > + =3D gdbarch_tdep (regcache->arch ()); > + > + gdb_assert (tdep->has_poe ()); > + > + uint64_t user_poe; > + iovec iovec; > + > + iovec.iov_base =3D &user_poe; > + iovec.iov_len =3D sizeof (user_poe); > + > + int tid =3D get_ptrace_pid (regcache->ptid ()); > + if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_POE, &iovec) !=3D 0) > + perror_with_name (_("Unable to fetch POE register")); > + > + regcache->raw_supply (tdep->poe_regnum, &user_poe); > +} > + > +/* Store the NT_ARM_POE register contents from GDB's REGCACHE to the > + thread associated with REGCACHE. */ > + > +static void > +store_poeregs_to_thread (struct regcache *regcache) > +{ > + aarch64_gdbarch_tdep *tdep > + =3D gdbarch_tdep (regcache->arch ()); > + > + gdb_assert (tdep->has_poe ()); > + > + int tid =3D regcache->ptid ().lwp (); > + > + iovec iovec; > + uint64_t user_poe; > + iovec.iov_base =3D &user_poe; > + iovec.iov_len =3D sizeof (user_poe); > + > + regcache->raw_collect (tdep->poe_regnum, &user_poe); > + > + if (ptrace (PTRACE_SETREGSET, tid, NT_ARM_POE, &iovec) !=3D 0) > + perror_with_name (_("Unable to store POE register")); > +} > + > /* Store to the current thread the valid GCS register set in the GDB's > register array. */ These functions are fine, but they were added between fetch_gcsregs_from_thread and store_gcsregs_to_thread. For better organization of the file, they should be either before or after the GCS ones. > @@ -683,6 +732,9 @@ aarch64_fetch_registers (struct regcache *regcache, i= nt regno) > if (tdep->has_gcs_linux ()) > fetch_gcsregs_from_thread (regcache); > > + if (tdep->has_poe ()) > + fetch_poeregs_from_thread (regcache); > + > if (tdep->has_fpmr ()) > fetch_fpmr_from_thread (regcache); > } > @@ -722,6 +774,10 @@ aarch64_fetch_registers (struct regcache *regcache, = int regno) > && (regno =3D=3D tdep->gcs_reg_base || regno =3D=3D tdep->gcs_l= inux_reg_base > || regno =3D=3D tdep->gcs_linux_reg_base + 1)) > fetch_gcsregs_from_thread (regcache); > + /* POE register? */ > + else if (tdep->has_poe () && (regno =3D=3D tdep->poe_regnum)) > + fetch_poeregs_from_thread (regcache); > + Please remove the extra blank line here. > /* FPMR? */ > else if (tdep->has_fpmr () && (regno =3D=3D tdep->fpmr_regnum)) > fetch_fpmr_from_thread (regcache); > @@ -802,6 +858,9 @@ aarch64_store_registers (struct regcache *regcache, i= nt regno) > > if (tdep->has_fpmr ()) > store_fpmr_to_thread (regcache); > + > + if (tdep->has_poe ()) > + store_poeregs_to_thread (regcache); > } > /* General purpose register? */ > else if (regno < AARCH64_V0_REGNUM) > @@ -837,6 +896,10 @@ aarch64_store_registers (struct regcache *regcache, = int regno) > else if (tdep->has_fpmr () && regno =3D=3D tdep->fpmr_regnum) > store_fpmr_to_thread (regcache); > Please remove the extra blank line here. The else ifs should be joined. > + /* POE register? */ > + else if (tdep->has_poe () && regno =3D=3D tdep->poe_regnum) > + store_poeregs_to_thread (regcache); > + > /* PAuth registers are read-only. */ > } > > @@ -1024,6 +1087,9 @@ aarch64_linux_nat_target::read_description () > /* Check for FPMR. */ > features.fpmr =3D hwcap2 & HWCAP2_FPMR; > > + /* Check for POE support. */ > + features.poe =3D hwcap2 & HWCAP2_POE; > + > return aarch64_read_description (features); > } > > diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c > index f11eccc1bc1..4a6bc3158c8 100644 > --- a/gdb/aarch64-linux-tdep.c > +++ b/gdb/aarch64-linux-tdep.c > @@ -53,6 +53,7 @@ > > #include "arch/aarch64-fpmr-linux.h" > #include "arch/aarch64-gcs-linux.h" > +#include "arch/aarch64-poe-linux.h" > #include "arch/aarch64-mte.h" > #include "arch/aarch64-mte-linux.h" > #include "arch/aarch64-pauth-linux.h" This should be moved to the patch that makes use of the new header. > diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c > index 886e7ce1e7b..f1e1a9c7a19 100644 > --- a/gdb/aarch64-tdep.c > +++ b/gdb/aarch64-tdep.c > @@ -164,6 +164,11 @@ static const char *const aarch64_gcs_register_names[= ] =3D { > "gcspr" > }; > > +static const char *const aarch64_poe_register_names[] =3D { > + /* Permission Overlay Extension Register. */ > + "por_el0" > +}; > + > static const char *const aarch64_gcs_linux_register_names[] =3D { > /* Field in struct user_gcs. */ > "gcs_features_enabled", > @@ -4556,6 +4561,19 @@ aarch64_gdbarch_init (struct gdbarch_info info, st= ruct gdbarch_list *arches) > fpmr_regnum, "fpmr"); > } > > + int poe_regnum =3D -1; > + const struct tdesc_feature *feature_poe > + =3D tdesc_find_feature (tdesc, "org.gnu.gdb.aarch64.poe"); > + if (feature_poe !=3D nullptr) > + { > + poe_regnum =3D num_regs; > + for (i =3D 0; i < ARRAY_SIZE (aarch64_poe_register_names); i++) > + valid_p &=3D tdesc_numbered_register (feature_poe, tdesc_data.get (= ), > + poe_regnum + i, > + aarch64_poe_register_names[i]); > + num_regs++; > + } > + > int first_sme_regnum =3D -1; > int first_sme2_regnum =3D -1; > int first_sme_pseudo_regnum =3D -1; > diff --git a/gdb/aarch64-tdep.h b/gdb/aarch64-tdep.h > index dff05a08f84..8029725b145 100644 > --- a/gdb/aarch64-tdep.h > +++ b/gdb/aarch64-tdep.h > @@ -208,6 +208,16 @@ struct aarch64_gdbarch_tdep : gdbarch_tdep_base > return gcs_linux_reg_base !=3D -1; > } > > + /* POE register. This is -1 if no POE feature is available. */ > + int poe_regnum =3D -1; > + > + /* Returns true if the target supports the Linux POE feature. */ Remove the "Linux" word, since the feature isn't specific to it, and also because this header file isn't OS-specific. > + bool > + has_poe () const > + { > + return poe_regnum !=3D -1; > + } > + > /* First FPMR register. This is -1 if FPMR is not supported. */ > int fpmr_regnum =3D -1; > > @@ -224,7 +234,6 @@ aarch64_features_from_target_desc (const struct targe= t_desc *tdesc); > > extern int aarch64_process_record (struct gdbarch *gdbarch, > struct regcache *regcache, CORE_ADDR addr); > - > displaced_step_copy_insn_closure_up > aarch64_displaced_step_copy_insn (struct gdbarch *gdbarch, > CORE_ADDR from, CORE_ADDR to, This change is unrelated to this patch. > diff --git a/gdb/arch/aarch64.c b/gdb/arch/aarch64.c > index 2401a325b7b..a567938d06d 100644 > --- a/gdb/arch/aarch64.c > +++ b/gdb/arch/aarch64.c > @@ -28,6 +28,7 @@ > #include "../features/aarch64-sme2.c" > #include "../features/aarch64-tls.c" > #include "../features/aarch64-gcs.c" > +#include "../features/aarch64-poe.c" > #include "../features/aarch64-gcs-linux.c" > > /* See arch/aarch64.h. */ > @@ -77,6 +78,9 @@ aarch64_create_target_description (const aarch64_featur= es &features) > if (features.fpmr) > regnum =3D create_feature_aarch64_fpmr (tdesc.get (), regnum); > > + if (features.poe) > + regnum =3D create_feature_aarch64_poe (tdesc.get (), regnum); > + > return tdesc; > } > > diff --git a/gdb/arch/aarch64.h b/gdb/arch/aarch64.h > index cf7318cbe74..4e4b50f729e 100644 > --- a/gdb/arch/aarch64.h > +++ b/gdb/arch/aarch64.h > @@ -35,6 +35,7 @@ struct aarch64_features > bool pauth =3D false; > bool mte =3D false; > bool fpmr =3D false; > + bool poe =3D false; You should add a comment for this boolean, as mentioned by Matthieu and Luis. Luis gave a good suggestion for the comment. > diff --git a/gdb/features/aarch64-poe.xml b/gdb/features/aarch64-poe.xml > new file mode 100644 > index 00000000000..43ee09e01d6 > --- /dev/null > +++ b/gdb/features/aarch64-poe.xml > @@ -0,0 +1,12 @@ > + > + > + > + > + > + Please remove the extra blank line here. > + > + > diff --git a/gdb/nat/aarch64-poe-linux.h b/gdb/nat/aarch64-poe-linux.h > new file mode 100644 > index 00000000000..3d858d3ff92 > --- /dev/null > +++ b/gdb/nat/aarch64-poe-linux.h > @@ -0,0 +1,28 @@ > +/* Common native Linux definitions for AArch64 Permission Overlay Extens= ion. > + > + 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_NAT_AARCH64_POE_LINUX_H > +#define GDB_NAT_AARCH64_POE_LINUX_H > + This file should include so that the system definition is used if available. > +/* Feature check for Permission Overlay Extension. */ > +#ifndef HWCAP2_POE > +#define HWCAP2_POE (1ULL << 63) > +#endif /* HWCAP2_POE */ > + > +#endif /* GDB_NAT_AARCH64_POE_LINUX_H */ > diff --git a/include/elf/common.h b/include/elf/common.h > index 1ae68221a89..f811b8daeb5 100644 > --- a/include/elf/common.h > +++ b/include/elf/common.h > @@ -760,6 +760,8 @@ > /* Note: name must be "LINUX". = */ > #define NT_ARM_FPMR 0x40e /* AArch64 FPMR. */ > /* Note: name must be "LINUX". = */ > +#define NT_ARM_POE 0x40f /* AArch64 POE register. */ > + /* Note: name must be "LINUX". *= / > #define NT_ARM_GCS 0x410 /* AArch64 Guarded Control Stack > registers. */ > /* Note name must be "LINUX". = */ This file is under binutils' "jurisdiction", so you should move this change to the bfd/readelf patch. And consequently also move that patch to become the first of the series, since this patch needs the definition above. Finally, the bfd/readelf patch should be cc'd to the binutils mailing list. Or alternatively sent there separately from this series. -- Thiago (he/him) --_000_AS8PR08MB100995E349C5BFAF1F5A4BCAC9BE82AS8PR08MB10099eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

>> *  info registers por_el0
>> *  p $por_el0
>> *  p/x $por_el0
>> *  set $por_el0 =3D <value>
>
>One question, more about general policy on the AArch64 GDB port:
>
>Should the register name have the _el0 suffix? It's more than half of
>the register name (though tab completion helps).
>
>We don't currently have that suffix in the name of any register. And in=
>the case of Guarded Control Stack, I didn't add it. For native
>debugging, it will always be the register at EL0. For remote debugging,=
>I assumed the target would send the register corresponding to the
>current exception level in the inferior.
>
>Can there be a situation where it would be possible to see both the EL0=
>and EL1 (for example) registers at the same time? Or a situation where<= /div>
>the inferior is at EL1 but one wants to see the register at EL0, or
>vice-versa?
>

Thanks Thiago for the review. I'll address the other review comments and
post a new version of the patches.

I'm happy to follow the existing AArch64 GDB convention and expose the regi= ster
as `POR` for consistency.

That said, after discussing this with kernel/KVM developers, there are vali= d
debugging scenarios (e.g. KGDB or guest debugging via KVM/QEMU) where expos= ing
`POR_EL0`, `POR_EL1`, and `POR_EL2` simultaneously would be useful. This se= ems
like a broader GDB register naming issue rather than something specific to<= /div>
FEAT_S1POE.

CC'ing Mark Rutland and Marc Zyngier, who can provide more context on
those use cases.

Regards,
Srinath

From: Thiago Jung Bauermann= <thiago.bauermann@linaro.org>
Sent: 27 June 2026 07:06
To: Srinath Parvathaneni <Srinath.Parvathaneni@arm.com>
Cc: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; l= uis.machado.foss@gmail.com <luis.machado.foss@gmail.com>; guinevere@r= edhat.com <guinevere@redhat.com>; Ezra Sitorus <Ezra.Sitorus@arm.c= om>; Matthieu Longo <Matthieu.Longo@arm.com>
Subject: Re: [PATCH v2 1/7] gdb/aarch64: Add POR_EL0 register suppor= t for FEAT_S1POE
 
Hello Srinath,

<srinath.parvathaneni@arm.com> writes:

> From: Srinath Parvathaneni <srinath.parvathaneni@arm.com>
>
> Add support for the FEAT_S1POE POR_EL0 register on AArch64.
>
> This patch adds POR_EL0 to the AArch64 register set and reads/writes i= t
> using the NT_ARM_POE ptrace regset.
>
> With this change, POR_EL0 is available through:
> *  info registers
> *  info registers por_el0
> *  p $por_el0
> *  p/x $por_el0
> *  set $por_el0 =3D <value>

One question, more about general policy on the AArch64 GDB port:

Should the register name have the _el0 suffix? It's more than half of
the register name (though tab completion helps).

We don't currently have that suffix in the name of any register. And in
the case of Guarded Control Stack, I didn't add it. For native
debugging, it will always be the register at EL0. For remote debugging,
I assumed the target would send the register corresponding to the
current exception level in the inferior.

Can there be a situation where it would be possible to see both the EL0
and EL1 (for example) registers at the same time? Or a situation where
the inferior is at EL1 but one wants to see the register at EL0, or
vice-versa?

> ---
>  gdb/Makefile.in        &= nbsp;     |  2 ++
>  gdb/aarch64-linux-nat.c      | 66 +++++= +++++++++++++++++++++++++++++++
>  gdb/aarch64-linux-tdep.c     |  1 +
>  gdb/aarch64-tdep.c       &nbs= p;   | 18 ++++++++++
>  gdb/aarch64-tdep.h       &nbs= p;   | 11 +++++-
>  gdb/arch/aarch64-poe-linux.h | 29 ++++++++++++++++
>  gdb/arch/aarch64.c       &nbs= p;   |  4 +++
>  gdb/arch/aarch64.h       &nbs= p;   |  7 +++-
>  gdb/features/Makefile        = |  1 +
>  gdb/features/aarch64-poe.c   | 14 ++++++++
>  gdb/features/aarch64-poe.xml | 12 +++++++
>  gdb/nat/aarch64-poe-linux.h  | 28 +++++++++++++++
>  include/elf/common.h       &n= bsp; |  2 ++
>  13 files changed, 193 insertions(+), 2 deletions(-)
>  create mode 100644 gdb/arch/aarch64-poe-linux.h
>  create mode 100644 gdb/features/aarch64-poe.c
>  create mode 100644 gdb/features/aarch64-poe.xml
>  create mode 100644 gdb/nat/aarch64-poe-linux.h
>
> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
> index 57f384170ab..3dc9cd07dcb 100644
> --- a/gdb/Makefile.in
> +++ b/gdb/Makefile.in
> @@ -1292,6 +1292,7 @@ HFILES_NO_SRCDIR =3D \
>        arch/aarch32.h \
>        arch/aarch64-fpmr-linux.h \<= br> >        arch/aarch64-gcs-linux.h \ > +     arch/aarch64-poe-linux.h \
>        arch/aarch64.h \
>        arch/aarch64-insn.h \
>        arch/aarch64-mte.h \
> @@ -1540,6 +1541,7 @@ HFILES_NO_SRCDIR =3D \
>        namespace.h \
>        nat/aarch64-fpmr-linux.h \ >        nat/aarch64-gcs-linux.h \ > +     nat/aarch64-poe-linux.h \
>        nat/aarch64-hw-point.h \
>        nat/aarch64-linux.h \
>        nat/aarch64-linux-hw-point.h= \
> diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c
> index 52ace4aab41..54265920d69 100644
> --- a/gdb/aarch64-linux-nat.c
> +++ b/gdb/aarch64-linux-nat.c
> @@ -34,6 +34,7 @@
>  #include "arch/arm.h"
>  #include "nat/aarch64-fpmr-linux.h"
>  #include "nat/aarch64-gcs-linux.h"
> +#include "nat/aarch64-poe-linux.h"
>  #include "nat/aarch64-linux.h"
>  #include "nat/aarch64-linux-hw-point.h"
>  #include "nat/aarch64-mte-linux-ptrace.h"
> @@ -569,6 +570,54 @@ fetch_gcsregs_from_thread (regcache *regcache) >            = ;            &us= er_gcs.features_locked);
>  }

> +/* Fill GDB's register array with the POE register value from the cur= rent
> +   thread.  */
> +
> +static void
> +fetch_poeregs_from_thread (regcache *regcache)
> +{
> +  aarch64_gdbarch_tdep *tdep
> +    =3D gdbarch_tdep<aarch64_gdbarch_tdep> (regc= ache->arch ());
> +
> +  gdb_assert (tdep->has_poe ());
> +
> +  uint64_t user_poe;
> +  iovec iovec;
> +
> +  iovec.iov_base =3D &user_poe;
> +  iovec.iov_len =3D sizeof (user_poe);
> +
> +  int tid =3D get_ptrace_pid (regcache->ptid ());
> +  if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_POE, &iovec) != =3D 0)
> +    perror_with_name (_("Unable to fetch POE regi= ster"));
> +
> +  regcache->raw_supply (tdep->poe_regnum, &user_poe);<= br> > +}
> +
> +/* Store the NT_ARM_POE register contents from GDB's REGCACHE to the<= br> > +    thread associated with REGCACHE.  */
> +
> +static void
> +store_poeregs_to_thread (struct regcache *regcache)
> +{
> +  aarch64_gdbarch_tdep *tdep
> +    =3D gdbarch_tdep<aarch64_gdbarch_tdep> (regc= ache->arch ());
> +
> +  gdb_assert (tdep->has_poe ());
> +
> +  int tid =3D regcache->ptid ().lwp ();
> +
> +  iovec iovec;
> +  uint64_t user_poe;
> +  iovec.iov_base =3D &user_poe;
> +  iovec.iov_len =3D sizeof (user_poe);
> +
> +  regcache->raw_collect (tdep->poe_regnum, &user_poe);=
> +
> +  if (ptrace (PTRACE_SETREGSET, tid, NT_ARM_POE, &iovec) != =3D 0)
> +    perror_with_name (_("Unable to store POE regi= ster"));
> +}
> +
>  /* Store to the current thread the valid GCS register set in the= GDB's
>     register array.  */

These functions are fine, but they were added between
fetch_gcsregs_from_thread and store_gcsregs_to_thread. For better
organization of the file, they should be either before or after the GCS
ones.

> @@ -683,6 +732,9 @@ aarch64_fetch_registers (struct regcache *regcache= , int regno)
>        if (tdep->has_gcs_linux (= ))
>        fetch_gcsregs_from_thread (r= egcache);

> +      if (tdep->has_poe ())
> +     fetch_poeregs_from_thread (regcache);
> +
>        if (tdep->has_fpmr ()) >        fetch_fpmr_from_thread (regc= ache);
>      }
> @@ -722,6 +774,10 @@ aarch64_fetch_registers (struct regcache *regcach= e, int regno)
>           &&= (regno =3D=3D tdep->gcs_reg_base || regno =3D=3D tdep->gcs_linux_reg= _base
>            = ;   || regno =3D=3D tdep->gcs_linux_reg_base + 1))
>      fetch_gcsregs_from_thread (regcache); > +  /* POE register?  */
> +  else if (tdep->has_poe () && (regno =3D=3D tdep->= ;poe_regnum))
> +    fetch_poeregs_from_thread (regcache);
> +

Please remove the extra blank line here.

>    /* FPMR?  */
>    else if (tdep->has_fpmr () && (regno =3D= =3D tdep->fpmr_regnum))
>      fetch_fpmr_from_thread (regcache);
> @@ -802,6 +858,9 @@ aarch64_store_registers (struct regcache *regcache= , int regno)

>        if (tdep->has_fpmr ()) >        store_fpmr_to_thread (regcac= he);
> +
> +      if (tdep->has_poe ())
> +     store_poeregs_to_thread (regcache);
>      }
>    /* General purpose register?  */
>    else if (regno < AARCH64_V0_REGNUM)
> @@ -837,6 +896,10 @@ aarch64_store_registers (struct regcache *regcach= e, int regno)
>    else if (tdep->has_fpmr () && regno =3D= =3D tdep->fpmr_regnum)
>      store_fpmr_to_thread (regcache);


Please remove the extra blank line here. The else ifs should be joined.

> +  /* POE register?  */
> +  else if (tdep->has_poe () && regno =3D=3D tdep->= poe_regnum)
> +    store_poeregs_to_thread (regcache);
> +
>    /* PAuth registers are read-only.  */
>  }

> @@ -1024,6 +1087,9 @@ aarch64_linux_nat_target::read_description () >    /* Check for FPMR.  */
>    features.fpmr =3D hwcap2 & HWCAP2_FPMR;

> +  /* Check for POE support.  */
> +  features.poe =3D hwcap2 & HWCAP2_POE;
> +
>    return aarch64_read_description (features);
>  }

> diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c
> index f11eccc1bc1..4a6bc3158c8 100644
> --- a/gdb/aarch64-linux-tdep.c
> +++ b/gdb/aarch64-linux-tdep.c
> @@ -53,6 +53,7 @@

>  #include "arch/aarch64-fpmr-linux.h"
>  #include "arch/aarch64-gcs-linux.h"
> +#include "arch/aarch64-poe-linux.h"
>  #include "arch/aarch64-mte.h"
>  #include "arch/aarch64-mte-linux.h"
>  #include "arch/aarch64-pauth-linux.h"

This should be moved to the patch that makes use of the new header.

> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
> index 886e7ce1e7b..f1e1a9c7a19 100644
> --- a/gdb/aarch64-tdep.c
> +++ b/gdb/aarch64-tdep.c
> @@ -164,6 +164,11 @@ static const char *const aarch64_gcs_register_nam= es[] =3D {
>    "gcspr"
>  };

> +static const char *const aarch64_poe_register_names[] =3D {
> +  /* Permission Overlay Extension Register.  */
> +  "por_el0"
> +};
> +
>  static const char *const aarch64_gcs_linux_register_names[] =3D = {
>    /* Field in struct user_gcs.  */
>    "gcs_features_enabled",
> @@ -4556,6 +4561,19 @@ aarch64_gdbarch_init (struct gdbarch_info info,= struct gdbarch_list *arches)
>            = ;            &n= bsp;            = ;     fpmr_regnum, "fpmr");
>      }

> +  int poe_regnum =3D -1;
> +  const struct tdesc_feature *feature_poe
> +      =3D tdesc_find_feature (tdesc, "o= rg.gnu.gdb.aarch64.poe");
> +  if (feature_poe !=3D nullptr)
> +    {
> +      poe_regnum =3D num_regs;
> +      for (i =3D 0; i < ARRAY_SIZE (aarch= 64_poe_register_names); i++)
> +     valid_p &=3D tdesc_numbered_register (fe= ature_poe, tdesc_data.get (),
> +           &nb= sp;            =             &nb= sp;    poe_regnum + i,
> +           &nb= sp;            =             &nb= sp;    aarch64_poe_register_names[i]);
> +      num_regs++;
> +    }
> +
>    int first_sme_regnum =3D -1;
>    int first_sme2_regnum =3D -1;
>    int first_sme_pseudo_regnum =3D -1;
> diff --git a/gdb/aarch64-tdep.h b/gdb/aarch64-tdep.h
> index dff05a08f84..8029725b145 100644
> --- a/gdb/aarch64-tdep.h
> +++ b/gdb/aarch64-tdep.h
> @@ -208,6 +208,16 @@ struct aarch64_gdbarch_tdep : gdbarch_tdep_base >      return gcs_linux_reg_base !=3D -1;
>    }

> +  /* POE register.  This is -1 if no POE feature is availab= le.  */
> +  int poe_regnum =3D -1;
> +
> +  /* Returns true if the target supports the Linux POE feature.&= nbsp; */

Remove the "Linux" word, since the feature isn't specific to it, = and
also because this header file isn't OS-specific.

> +  bool
> +  has_poe () const
> +  {
> +    return poe_regnum !=3D -1;
> +  }
> +
>    /* First FPMR register.  This is -1 if FPMR is = not supported.  */
>    int fpmr_regnum =3D -1;

> @@ -224,7 +234,6 @@ aarch64_features_from_target_desc (const struct ta= rget_desc *tdesc);

>  extern int aarch64_process_record (struct gdbarch *gdbarch,
>            = ;            &n= bsp;      struct regcache *regcache, CORE_ADDR add= r);
> -
>  displaced_step_copy_insn_closure_up
>    aarch64_displaced_step_copy_insn (struct gdbarch *gd= barch,
>            = ;            &n= bsp;           CORE_ADDR = from, CORE_ADDR to,

This change is unrelated to this patch.

> diff --git a/gdb/arch/aarch64.c b/gdb/arch/aarch64.c
> index 2401a325b7b..a567938d06d 100644
> --- a/gdb/arch/aarch64.c
> +++ b/gdb/arch/aarch64.c
> @@ -28,6 +28,7 @@
>  #include "../features/aarch64-sme2.c"
>  #include "../features/aarch64-tls.c"
>  #include "../features/aarch64-gcs.c"
> +#include "../features/aarch64-poe.c"
>  #include "../features/aarch64-gcs-linux.c"

>  /* See arch/aarch64.h.  */
> @@ -77,6 +78,9 @@ aarch64_create_target_description (const aarch64_fea= tures &features)
>    if (features.fpmr)
>      regnum =3D create_feature_aarch64_fpmr (= tdesc.get (), regnum);

> +  if (features.poe)
> +    regnum =3D create_feature_aarch64_poe (tdesc.get (= ), regnum);
> +
>    return tdesc;
>  }

> diff --git a/gdb/arch/aarch64.h b/gdb/arch/aarch64.h
> index cf7318cbe74..4e4b50f729e 100644
> --- a/gdb/arch/aarch64.h
> +++ b/gdb/arch/aarch64.h
> @@ -35,6 +35,7 @@ struct aarch64_features
>    bool pauth =3D false;
>    bool mte =3D false;
>    bool fpmr =3D false;
> +  bool poe =3D false;

You should add a comment for this boolean, as mentioned by Matthieu and
Luis. Luis gave a good suggestion for the comment.

> diff --git a/gdb/features/aarch64-poe.xml b/gdb/features/aarch64-poe.x= ml
> new file mode 100644
> index 00000000000..43ee09e01d6
> --- /dev/null
> +++ b/gdb/features/aarch64-poe.xml
> @@ -0,0 +1,12 @@
> +<?xml version=3D"1.0"?>
> +<!-- Copyright (C) 2026 Free Software Foundation, Inc.
> +
> +     Copying and distribution of this file, with = or without modification,
> +     are permitted in any medium without royalty = provided the copyright
> +     notice and this notice are preserved.  = -->
> +
> +<!DOCTYPE feature SYSTEM "gdb-target.dtd">
> +<feature name=3D"org.gnu.gdb.aarch64.poe">
> +

Please remove the extra blank line here.

> +  <reg name=3D"por_el0" bitsize=3D"64" ty= pe=3D"uint64" group=3D"system"/>
> +</feature>
> diff --git a/gdb/nat/aarch64-poe-linux.h b/gdb/nat/aarch64-poe-linux.h=
> new file mode 100644
> index 00000000000..3d858d3ff92
> --- /dev/null
> +++ b/gdb/nat/aarch64-poe-linux.h
> @@ -0,0 +1,28 @@
> +/* Common native Linux definitions for AArch64 Permission Overlay Ext= ension.
> +
> +   Copyright (C) 2026 Free Software Foundation, Inc.
> +
> +   This file is part of GDB.
> +
> +   This program is free software; you can redistribute it a= nd/or modify
> +   it under the terms of the GNU General Public License as = published by
> +   the Free Software Foundation; either version 3 of the Li= cense, 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 warra= nty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.&nbs= p; See the
> +   GNU General Public License for more details.
> +
> +   You should have received a copy of the GNU General Publi= c License
> +   along with this program.  If not, see <http://www.gnu.org/licenses/>.&nbs= p; */
> +
> +#ifndef GDB_NAT_AARCH64_POE_LINUX_H
> +#define GDB_NAT_AARCH64_POE_LINUX_H
> +

This file should include <asm/hwcap.h> so that the system definition = is
used if available.

> +/* Feature check for Permission Overlay Extension.  */
> +#ifndef HWCAP2_POE
> +#define HWCAP2_POE (1ULL << 63)
> +#endif /* HWCAP2_POE */
> +
> +#endif /* GDB_NAT_AARCH64_POE_LINUX_H */
> diff --git a/include/elf/common.h b/include/elf/common.h
> index 1ae68221a89..f811b8daeb5 100644
> --- a/include/elf/common.h
> +++ b/include/elf/common.h
> @@ -760,6 +760,8 @@
>            = ;            &n= bsp;            = ;   /*   Note: name must be "LINUX".  */=
>  #define NT_ARM_FPMR     0x40e  &nb= sp;        /* AArch64 FPMR.  */
>            = ;            &n= bsp;            = ;   /*   Note: name must be "LINUX".  */=
> +#define NT_ARM_POE   0x40f     &nb= sp;     /* AArch64 POE register.  */
> +           &nb= sp;            =              /*=    Note: name must be "LINUX".  */
>  #define NT_ARM_GCS   0x410    &nbs= p;      /* AArch64 Guarded Control Stack
>            = ;            &n= bsp;            = ;      registers.  */
>            = ;            &n= bsp;            = ;   /*   Note  name must be "LINUX".&nbs= p; */

This file is under binutils' "jurisdiction", so you should move t= his
change to the bfd/readelf patch. And consequently also move that patch
to become the first of the series, since this patch needs the definition above.

Finally, the bfd/readelf patch should be cc'd to the binutils mailing
list. Or alternatively sent there separately from this series.

--
Thiago
(he/him)
--_000_AS8PR08MB100995E349C5BFAF1F5A4BCAC9BE82AS8PR08MB10099eu_--