From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6AY9NxEZQmryIR0AWB0awg (envelope-from ) for ; Mon, 29 Jun 2026 03:04:49 -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=fRxbNbsq; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=fRxbNbsq; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C63D41E070; Mon, 29 Jun 2026 03:04:49 -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 [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 C30D51E070 for ; Mon, 29 Jun 2026 03:04:47 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 593F94BA2E24 for ; Mon, 29 Jun 2026 07:04:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 593F94BA2E24 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=fRxbNbsq; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=fRxbNbsq Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazlp170130007.outbound.protection.outlook.com [IPv6:2a01:111:f403:c20f::7]) by sourceware.org (Postfix) with ESMTPS id 78D164BA2E1D for ; Mon, 29 Jun 2026 07:04:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 78D164BA2E1D 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 78D164BA2E1D Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c20f::7 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1782716652; cv=pass; b=EPvpEzG1vRXsLeZ4YJfoo6+/Kk395vhdUBLQRiURkeZX5x9nZmyq6kEXg/XZMlDYy8Jwwb+4oLdDvmIqeZ88+7z1DyHUhchyU/1JBNhBhXy/IxHSTUaHanj6Tj40u6/Tjr4wunZ9iFv1+sJPJFfAlgYiqwcckQ+Z24aan/L78uw= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1782716652; c=relaxed/simple; bh=teloIDapV54SJhAQDqmIL1stm0njG/NmhrW/VqSCvmM=; h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID: MIME-Version; b=l3eTQATtzw3wlaBG5uTDpgqlwvaslVknIVLq1yPS4Q8+44nOyqUYex5x+myKPPqFo1QaIdh32J+EFZWQukxxvEa4Z4ZLEqSKyJHI79efHuNamzP7KGXn1p13iK1lucYM6lIzNrioONnX8NaLlzKpaCS4Oqm1prJjexqQKstNuKU= 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=fRxbNbsq; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=fRxbNbsq DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78D164BA2E1D ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=VJjF1/R0mjSjyCAIu+4Fs5tcI+/yTFxBj4xJgGlbWYR3cxuTqfI+qwF4IMh2V6P4+KDJvQQAp4dE6BDlc3onh4ZoW/uF0XfuWCRzdp107A4KEqJITnIXsLGgv/j9Q2exKZYjkYSis+rC6Yv4tC4qQ6gKztGD5Oi0hLEycPYbXQO868K2VnFB+uex3t/uHsa92iGILQWoPwWIkpBnrLUVRiGcLqUO3ujNpkocoURnOgDX5xKcm0pZCq6DOBjoAH/qx3LhfTi919jxP1nDWZwH2ie55lTYE1+ZBFDUXRmhszvUFXpLytcXRNxIC9nITtewFY9KV4bK6s06NNP+2JBQtw== 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=5EzjYwr8LkF+y5KNptQ5x2mVPR3BPK/rjpekPKXUPXk=; b=VMB8JnBPUD6GNdj1xRLUcgnmgCfhv57KeZ618JlO3vduhWdXwZu4V7v9zTnFBv4FXnWhv3pINbQj822P5e8lhYh+wN+JwQA0SxFJG5K6kVpkZNVEWeZY/CdJqhwAAVWMq2sL03zdwCawstgDAyf3n4sf4N6Ln9t8ewxEEhZr6I9kuVq+C5gSfgSPGXcUDwLYV9g+y5+2/M9eTErOwEWzItHLs3d/bUbEJSJyFrdyPhYYYpLHGfJtn1BRFp4knxWJGr3+D9ZaVpRIZmHo2TD+Ep+f58QorxvdD+AU7M9+yasm7XsULTKNEyyzXec0KbSRfDa34PYZKg8BOlN0CP6x6A== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linaro.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=5EzjYwr8LkF+y5KNptQ5x2mVPR3BPK/rjpekPKXUPXk=; b=fRxbNbsqYMYC1w89TIA4DNZL7yPzgB0E+PN441WuZuJTsneq9x6kALxCgm3Ww3tBKbLuSq+G21L5hyyyb7arPWlFQj5W4L4a3h6YT0o3iAFKI7QyD4gpAsq4uK07E2JYtv0BLILxb6qctTQ59qFgJFct6LECq4n9z/T2EYzbTBE= Received: from DU7P190CA0027.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:550::13) by VI1PR08MB10050.eurprd08.prod.outlook.com (2603:10a6:800:1c4::5) 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 07:03:45 +0000 Received: from DU2PEPF00028D09.eurprd03.prod.outlook.com (2603:10a6:10:550:cafe::a2) by DU7P190CA0027.outlook.office365.com (2603:10a6:10:550::13) 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 07:03:45 +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 DU2PEPF00028D09.mail.protection.outlook.com (10.167.242.169) 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 07:03:44 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YMUwBJnqCuUjjVQStufYu5Fqa4c0fE6BsAZLR+C3GQYOlA+7Xhao9CQTwGD30fEUyvhAlU7RpUROL0wVRdpswE5Kb6hVl6YydvMUO3RzdhN34uzCRia9TM5sEMfggCGarNg4B/79zqhh75xW7Vf+SzeubneCxx7KG5y3bcFQ6ejY2tn4Pq9Q5wUiGYqZ4KG6RnfoxTCQfzIN3Z5qerBGBYsvaCeSMovw5+XeVL/qonXRlRhX5PMiaWEaFhhHctb70ld0r6/7q0R27S1cKMdvkwg92AVBvR2aR13y4/Lsk6+D+ZTEV90n65lCVXGY685T7mnpNBn9pDWl1XHMthx1iw== 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=5EzjYwr8LkF+y5KNptQ5x2mVPR3BPK/rjpekPKXUPXk=; b=Q6rTZikPVFV5xcghWZLhAGlsZdR9HFYoQLnoy7QZPHm/P4XcYg/FD8k+ZphvDo2eNJKGwyAJxiYSpQXTy3sK/yXKIWfJE4j227hgrhRZOPXXTD9fwPUJnFSzVTA8+coZRAGvw2F7DnQbh33Hvb/BCKy7fFhfM1P+9X/n2WxZ1JxuImEwENKUJdD3MrQpfANUtyj+WgPybV7xPbWLKlwcuVlU2ukb4j4y3en+T8ZT6rIaQeyxz7RHf/gaOdbbSH4ODOlPYbgtiTFaAbqZGD4dFrqSNVPVMQSSz/cDjQdZMWaJ2BnvPdJOhe963SLGkntkkTtABcqPfqUjEq8SxUFr8A== 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=5EzjYwr8LkF+y5KNptQ5x2mVPR3BPK/rjpekPKXUPXk=; b=fRxbNbsqYMYC1w89TIA4DNZL7yPzgB0E+PN441WuZuJTsneq9x6kALxCgm3Ww3tBKbLuSq+G21L5hyyyb7arPWlFQj5W4L4a3h6YT0o3iAFKI7QyD4gpAsq4uK07E2JYtv0BLILxb6qctTQ59qFgJFct6LECq4n9z/T2EYzbTBE= Received: from AS8PR08MB10099.eurprd08.prod.outlook.com (2603:10a6:20b:628::5) by FRZPR08MB11070.eurprd08.prod.outlook.com (2603:10a6:d10:138::18) 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 07:02:41 +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 07:02:39 +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 Subject: Re: [PATCH v2 2/7] gdb/aarch64: Add custom printing for POR_EL0 Thread-Topic: [PATCH v2 2/7] gdb/aarch64: Add custom printing for POR_EL0 Thread-Index: AQHdBZbQzVwidcuk4kaZlFn6AjkbyrZR+utqgAMkIDw= Date: Mon, 29 Jun 2026 07:02:38 +0000 Message-ID: References: <20260626180821.376406-1-srinath.parvathaneni@arm.com> <20260626180821.376406-3-srinath.parvathaneni@arm.com> <87y0g0h3d6.fsf@linaro.org> In-Reply-To: <87y0g0h3d6.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_|FRZPR08MB11070:EE_|DU2PEPF00028D09:EE_|VI1PR08MB10050:EE_ X-MS-Office365-Filtering-Correlation-Id: 385c9883-d6e0-4331-2b18-08ded5ac8f4c 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|18002099003|22082099003|38070700021|4143699003|11063799006|56012099006|13003099007|3023799007|8096899003; X-Microsoft-Antispam-Message-Info-Original: ekn2It8owLaq8Mp4R5faAI7pJcVGjaQhwowNtgmGho+83jnttuL8Ey6tt2NgEG01ySz4GMBMZ/5Tx7cQ9mCypbAv7qRL1/2kC1C10ZT7cKu0UoFXcVVlMJ4HJugMHVM+QWdA59aNr307GNwzwmYGSEmNyz9ei7lWU5fZex4pXz/LcuQHu6FSWrCY7+sZx69pTLYaYgS8nKVa0FNk2tpLWSd55jk1tHO2mBK9SV0MFYx3MV2JAAcYYILt58PyeN5hEea8NuHSWm1KztWKF1Ue/dlXrWnT7Jo/UIT23L0+j6iWylzkvZl8J4jTVvEDjhB9weQL+4SQHp2smQqlr2K/nok4elcRpDU2MKw2Z9fB/wQjFCCFn+ir9YFUiOY8ABY3LGFDG8AOSo6KnqEGTWGKRsUt0m5Z5QTQu1lmQMW3kFad0USmwY5r3rxWFd42hDAT+X2BXISavwGIOmBg4diAEUCD0CimD0j1yZDvhk1VaQNoaDcQ9805khN9UZmySS0hyDDVHGPZi08ZeAK5t45GY8EH2PjHpvRKnAatj0fyY8/6Qe4Rxa+CI2M1WZJdacoI/bOkzSXmKi+t9d95HuROVmYXicPS12wPehNB0/sIlTTdIiFkggCq9hAoHhIszJ2I4hnWIPhyf4AR/wm55O9Cvdb/WYBA/hw9Q8mwJ+OZ39vUJGyxx6PftsNmJCQZmPQ8arjRuwEk+jZuTZBeDjmXtVqOBuApODr32DrSEUK1+Qg= 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)(18002099003)(22082099003)(38070700021)(4143699003)(11063799006)(56012099006)(13003099007)(3023799007)(8096899003); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_AS8PR08MB10099AF828BCAA07C846ED62E9BE82AS8PR08MB10099eu_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: l36nclRtZv8htqaXFlB+KXrg3zAhFO5cwO0tZF+uJp5a3n2qjk1GDI0OfP5rGIwW5cCZR6NfBJBnipdOpi4l7j8gCIf1ILi8Z35nh4Xf9gg/41chtIx4qdpiLmQi+/+m51q+42kzEJgCc0lR+rCBszwKl8mtAFuNt/IWDfnFkfLAo1HbartnEHeCOXMU3yOtYjDGE1XEgxOUjnAurWWO0X7rP01RSG0l4Py6G+HwsN1aRa10gPZ/lGcv37wskOVniOd37v6x2qb2q/jwAiStOF03V0OsHPxvDDtDJrVQCHcBkUxIW/jm53a5OR9gON9poQtudpfVkSN7dChPPPbnPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRZPR08MB11070 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF00028D09.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 34d87e24-f6cc-4846-9fef-08ded5ac6814 X-Microsoft-Antispam: BCL:0; ARA:13230040|14060799003|35042699022|376014|82310400026|1800799024|36860700016|23010399003|18002099003|22082099003|3023799007|8096899003|13003099007|11063799006|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: oJIdxJzUWg/+YaePxBkhcyM8S8QrBpVoH4CveX/eoD9BkqC99e2uOLGmkpTdlb7TyZQx02mn/JAOVWly8itzGZ4iQiCI6OzYrc0K/8sua3foYF8azmn6GE/rK4bFnpO8Xn4K0f0ldtnUfgG7ATikTkISED4gNXGHo8L44K38CK3TBrvJdaG5v3LWOu7tcUXTG7TPEXZBOaMMq6yElawmS77nYiH5YA76M7+2I7LZFkHPSjwiQFyQBZPlQwFkAtjHJlXHILMvfEYt3YDUw7ALzIG9HE23KcrU7h9IDNsVnQAfYPGfP1weujThFUcY2zwwM2ZCphcv1A9N/c/3t2O5J/41uTPlniXDXMgxNDIGS4UftrEd66uVvok5KZukqQwaafqEZDtMUmRp8jeEgowHLMhvsOrla77YZpfAlwDg+JYnEpuWH4LfxbaL9AgIYBaaBaFh52UBouqg0ZnpYwnqQc0BmIi6JCDlHwaoOWnDZhf0Hl+aX/Wg56owXtGVUq3o2uDc653vJlGi37D4YZSA0KK3DP/pv4qbMxStD+tbZxjYYwjVDsp0HOAwivSvhQjMaA56Jj0zzV7kNiRNMdJTPtC7QmXz+Iyx29sTrrDYSpitir+Tf8Kvp8tV8QUIsWWZZIcoIWYa+deHK2H983bLNMi+DoXkITgndthqMZIampwaIFRYBIJNDSqs4k0cHjHrHKgtRu7NxCKP8SRLqP3W3w== 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)(14060799003)(35042699022)(376014)(82310400026)(1800799024)(36860700016)(23010399003)(18002099003)(22082099003)(3023799007)(8096899003)(13003099007)(11063799006)(4143699003)(56012099006); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: wuUSfYUPhrsu1i4jcDYPtPDO4yd0BTJca8+TBAt1OUVN92zBlZah6eCIO9Rr0FQzMrUGAltCeLDT39+6d98Wyeg3kSROSQj0L3KslMpZ665Sl8raCvR1BVvep+ulUkGiTOWscmId5i/2Yg5PF6kIsb+PXEPToGh8D+1SMmBjm5HcVjWnvXGz7drgZFAhVSDD3Cue5OBH15X/EOmjNZDv+ruwRG5bwEv89I0j2T3lPT83wTLTTxFy/rj7CuCSYgBL4jiAYwoxV9VMW6YhVRG2kSXfMgTALFnH/MBBfzBG3LYEYyEu03m3uygVSpAGqPJByXiJr2jG8Ojb36Pexta1dAuDe+YibgEMusQzC1c+IjI+z+UQaqNUFQz5hoSGfCQNlkbqqpWXzYIpqph1okVuAPUdnxgBtJyNnZK/g+UKiPNh8Yeb+wK0ebt1WDGAjwa1 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2026 07:03:44.7295 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 385c9883-d6e0-4331-2b18-08ded5ac8f4c 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: DU2PEPF00028D09.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB10050 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_AS8PR08MB10099AF828BCAA07C846ED62E9BE82AS8PR08MB10099eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, > >Instead of adding this gdbarch hook, have you considered using enum >target types=B9 in the feature XML instead? E.g: > > > > > > > > > > > > > > > > > > > > > > > > >Note that I haven't tested the above and I'm not sure it would actually >work (or work well). > >I see two advantages: > >- It works in the "print $por_el0" case too, not only "info register > $por_el0". Or does this patch also work with "print $por_el0" as well? > >- It's less code. > Thanks Thiago for the review. I'll address the other review comments and post a new version of the patches. The approach you suggested above is actually what I used in v1 (https://sourceware.org/pipermail/gdb-patches/2026-June/228082.html). With that approach, I was able to display the custom string for info registers, info all-registers, and print $por_el0. However, the problem I faced was when the register type was por_flags. In that case, "set $por_el0 =3D " failed with an "Invalid case" erro= r. Because of this, I had to drop support for writing to por_el0 in the initia= l version of the patch. When I tried to resolve this, the only approach I found was to use type=3D"uint64_t" so that set works and I have implement the custom string handling specifically for info register $por_el0. The downside is that this= does not affect print $por_el0. If you have any suggestions for avoiding the "Invalid case" issue with set $por_el0 =3D , I'd be happy to switch back to the original XML approach from v1. Regards Srinath. ________________________________ From: Thiago Jung Bauermann Sent: 27 June 2026 08:03 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 2/7] gdb/aarch64: Add custom printing for POR_EL0 writes: > From: Srinath Parvathaneni > > Add custom printing support for the POR_EL0 register when displayed > using `info registers` or `info all-registers`. > > The register value is decoded into a human-readable "rwx" > representation for each nibble in the POR_EL0 register, making the > POE permissions easier to interpret. > > Example: > (gdb) set $por_el0=3D0xffffffff77777777 > (gdb) info register por_el0 > por_el0 0xffffffff77777777 [P15=3D??? P14=3D??? P13=3D??? P12=3D?= ?? P11=3D??? P10=3D??? P9=3D??? P8=3D??? P7=3Drwx P6=3Drwx P5=3Drwx P4=3Drw= x P3=3Drwx P2=3Drwx P1=3Drwx P0=3Drwx ] Nice. > --- > gdb/aarch64-tdep.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 86 insertions(+) > > diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c > index f1e1a9c7a19..3ef4e696c7c 100644 > --- a/gdb/aarch64-tdep.c > +++ b/gdb/aarch64-tdep.c > @@ -3135,6 +3135,86 @@ aarch64_pseudo_register_type (struct gdbarch *gdba= rch, int regnum) > p_regnum); > } > > +/* Convert a POR_EL0 Perm overlay permission encoding into rwx-style = string. > + For example: > + 0b0011 -> "r-x" (3) > + 0b0101 -> "rw-" (5) > + 0b0111 -> "rwx" (7) > + 0b0000 -> "---" (0) > + Reserved encodings (0b1xxx) are returned as "???". */ > + > +static const char* > +aarch64_perm_overlay_decode (unsigned int perm) > +{ > + switch (perm) > + { > + case 0: return "---"; > + case 1: return "r--"; > + case 2: return "--x"; > + case 3: return "r-x"; > + case 4: return "-w-"; > + case 5: return "rw-"; > + case 6: return "-wx"; > + case 7: return "rwx"; > + default: return "???"; > + } > +} > + > +/* Display POE reigster POR_EL0 in the following format for the 'info re= gisters' Typo: reigster > + and 'info all-registers' commands: > + [= ] */ > + > +static void > +aarch64_print_poe_register_info (struct ui_file *file, > + int regnum, > + const char *name, > + const frame_info_ptr &frame) > +{ > + value *val =3D value_of_register (regnum, get_next_frame_sentinel_okay= (frame)); > + ULONGEST por_el0 =3D (ULONGEST) value_as_long (val); > + gdb_printf (file, "%-14s 0x%s [", name, phex_nz (por_el0, 8)); > + > + for (int i =3D 15; i >=3D 0; --i) > + { > + unsigned int perm =3D (por_el0 >> (i * 4)) & 0xf; > + gdb_printf (file, "P%d=3D%s ", i, aarch64_perm_overlay_decode (per= m)); > + } > + > + gdb_puts ("]\n", file); > +} > + > +/* For 'info registers' and 'info all-registers', print POR_EL0 using th= e > + custom POE register printer and all other registers using the default > + register printer. */ > + > +static void > +aarch64_print_registers_info (struct gdbarch *gdbarch, > + struct ui_file *file, > + const frame_info_ptr &frame, > + int regnum, > + bool print_all) > +{ > + const int numregs =3D gdbarch_num_cooked_regs (gdbarch); > + aarch64_gdbarch_tdep *tdep =3D gdbarch_tdep (gdb= arch); > + > + if (regnum =3D=3D -1) > + { > + for (int i =3D 0; i < numregs; i++) > + { > + if (i =3D=3D tdep->poe_regnum) > + { > + aarch64_print_poe_register_info (file, i, "por_el0", frame); > + continue; > + } > + default_print_registers_info (gdbarch, file, frame, i, print_all= ); > + } > + } > + else if (regnum =3D=3D tdep->poe_regnum) > + aarch64_print_poe_register_info (file, regnum, "por_el0", frame); > + else > + default_print_registers_info (gdbarch, file, frame, regnum, print_al= l); > +} > + > /* Implement the "pseudo_register_reggroup_p" tdesc_arch_data method. *= / > > static bool Instead of adding this gdbarch hook, have you considered using enum target types=B9 in the feature XML instead? E.g: Note that I haven't tested the above and I'm not sure it would actually work (or work well). I see two advantages: - It works in the "print $por_el0" case too, not only "info register $por_el0". Or does this patch also work with "print $por_el0" as well? - It's less code. > @@ -4141,6 +4221,10 @@ aarch64_features_from_target_desc (const struct ta= rget_desc *tdesc) > features.fpmr =3D (tdesc_find_feature (tdesc, "org.gnu.gdb.aarch64.fpm= r") > !=3D nullptr); > > + /* Check for POE feature. */ > + features.poe =3D (tdesc_find_feature (tdesc, "org.gnu.gdb.aarch64.poe"= ) > + !=3D nullptr); > + > return features; > } > > @@ -4774,6 +4858,7 @@ aarch64_gdbarch_init (struct gdbarch_info info, str= uct gdbarch_list *arches) > tdep->gcs_reg_base =3D first_gcs_regnum; > tdep->gcs_linux_reg_base =3D first_gcs_linux_regnum; > tdep->fpmr_regnum =3D fpmr_regnum; > + tdep->poe_regnum =3D poe_regnum; > > /* Set the SME register set details. The pseudo-registers will be adj= usted > later. */ This change and the one above it in aarch64_features_from_target_desc should be in the previous patch instead. -- Thiago (he/him) =B9 https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Type= s.html#Enum-Target-Types --_000_AS8PR08MB10099AF828BCAA07C846ED62E9BE82AS8PR08MB10099eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

>
>Instead of adding this gdbarch hook, have you considered using enum
>target types=B9 in the feature XML instead? E.g:
>
><feature name=3D"org.gnu.gdb.aarch64.poe">
>  <enum id=3D"perms_enum" size=3D"4">
>    <evalue name=3D"---" value=3D"0"/&= gt;
>    <evalue name=3D"r--" value=3D"1"/&= gt;
>    <evalue name=3D"r-x" value=3D"2"/&= gt;
>    <evalue name=3D"r-x" value=3D"3"/&= gt;
>    <evalue name=3D"-w-" value=3D"4"/&= gt;
>    <evalue name=3D"rw-" value=3D"5"/&= gt;
>    <evalue name=3D"-wx" value=3D"6"/&= gt;
>    <evalue name=3D"rwx" value=3D"7"/&= gt;
>    <!-- Maybe add the other 8 values as "???"? = -->
>  </enum>
>  <flags id=3D"por_flags" size=3D"8">
>    <field name=3D"P0" start=3D"0" end= =3D"3" type=3D"perms_enum"/>
>    <field name=3D"P1" start=3D"4" end= =3D"7" type=3D"perms_enum"/>
>    <field name=3D"P2" start=3D"8" end= =3D"11" type=3D"perms_enum"/>
>    <field name=3D"P3" start=3D"12" en= d=3D"15" type=3D"perms_enum"/>
>    <!-- And so on until P15. -->
>  </flags>
>
>  <reg name=3D"por_el0" bitsize=3D"64" type= =3D"por_flags" group=3D"system"/>
></feature>
>
>Note that I haven't tested the above and I'm not sure it would actually=
>work (or work well).
>
>I see two advantages:
>
>- It works in the "print $por_el0" case too, not only "i= nfo register
>  $por_el0". Or does this patch also work with "print $p= or_el0" as well?
>
>- It's less code.
>

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

The approach you suggested above is actually what I used in v1
(https://sourceware.org/pipermail/gdb-patches/2026-June/228082.html).
With that approach, I was able to display the custom string for
info registers, info all-registers, and print $por_el0.

However, the problem I faced was when the register type was por_flags.
In that case, "set $por_el0 =3D <value>" failed with an &qu= ot;Invalid case" error.
Because of this, I had to drop support for writing to por_el0 in the initia= l
version of the patch.

When I tried to resolve this, the only approach I found was to use
type=3D"uint64_t" so that set works and I have implement the cust= om string
handling specifically for info register $por_el0. The downside is that this= does
not affect print $por_el0.

If you have any suggestions for avoiding the "Invalid case" issue= with
set $por_el0 =3D <value>, I'd be happy to switch back to the original= XML
approach from v1.

Regards
Srinath.

From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>=
Sent: 27 June 2026 08:03
To: Srinath Parvathaneni <Srinath.Parvathaneni@arm.com> Cc: gdb-patches@sourceware.org <gdb-patches@sourceware.org&g= t;; luis.machado.foss@gmail.com <luis.machado.foss@gmail.com>; guinev= ere@redhat.com <guinevere@redhat.com>; Ezra Sitorus <Ezra.Sitorus@= arm.com>; Matthieu Longo <Matthieu.Longo@arm.com>
Subject: Re: [PATCH v2 2/7] gdb/aarch64: Add custom printing fo= r POR_EL0
 
<srinath.parvathaneni@arm.com> writes= :

> From: Srinath Parvathaneni <srinath.parvathaneni@arm.com>
>
> Add custom printing support for the POR_EL0 register when displayed > using `info registers` or `info all-registers`.
>
> The register value is decoded into a human-readable "rwx" > representation for each nibble in the POR_EL0 register, making the
> POE permissions easier to interpret.
>
> Example:
> (gdb) set $por_el0=3D0xffffffff77777777
> (gdb) info register por_el0
> por_el0        0xffffffff77777777&n= bsp; [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 ]

Nice.

> ---
>  gdb/aarch64-tdep.c | 86 ++++++++++++++++++++++++++++++++++++++++= ++++++
>  1 file changed, 86 insertions(+)
>
> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
> index f1e1a9c7a19..3ef4e696c7c 100644
> --- a/gdb/aarch64-tdep.c
> +++ b/gdb/aarch64-tdep.c
> @@ -3135,6 +3135,86 @@ aarch64_pseudo_register_type (struct gdbarch *g= dbarch, int regnum)
>            = ;      p_regnum);
>  }
> 
> +/* Convert a POR_EL0 Perm<m> overlay permission encoding into r= wx-style string.
> +   For example:
> +     0b0011 -> "r-x" (3)
> +     0b0101 -> "rw-" (5)
> +     0b0111 -> "rwx" (7)
> +     0b0000 -> "---" (0)
> +   Reserved encodings (0b1xxx) are returned as "???&qu= ot;.  */
> +
> +static const char*
> +aarch64_perm_overlay_decode (unsigned int perm)
> +{
> +  switch (perm)
> +   {
> +     case 0: return "---";
> +     case 1: return "r--";
> +     case 2: return "--x";
> +     case 3: return "r-x";
> +     case 4: return "-w-";
> +     case 5: return "rw-";
> +     case 6: return "-wx";
> +     case 7: return "rwx";
> +     default: return "???";
> +   }
> +}
> +
> +/* Display POE reigster POR_EL0 in the following format for the 'info= registers'

Typo: reigster

> +   and 'info all-registers' commands:
> +   <register-name> <hex-value> [<decoded per= -protection-key permissions>]  */
> +
> +static void
> +aarch64_print_poe_register_info (struct ui_file *file,
> +           &nb= sp;            =       int regnum,
> +           &nb= sp;            =       const char *name,
> +           &nb= sp;            =       const frame_info_ptr &frame)
> +{
> +  value *val =3D value_of_register (regnum, get_next_frame_senti= nel_okay (frame));
> +  ULONGEST por_el0 =3D (ULONGEST) value_as_long (val);
> +  gdb_printf (file, "%-14s 0x%s  [", name, phex_n= z (por_el0, 8));
> +
> +  for (int i =3D 15; i >=3D 0; --i)
> +    {
> +      unsigned int perm =3D (por_el0 >>= ; (i * 4)) & 0xf;
> +      gdb_printf (file, "P%d=3D%s "= ;, i, aarch64_perm_overlay_decode (perm));
> +    }
> +
> +  gdb_puts ("]\n", file);
> +}
> +
> +/* For 'info registers' and 'info all-registers', print POR_EL0 using= the
> +   custom POE register printer and all other registers usin= g the default
> +   register printer.  */
> +
> +static void
> +aarch64_print_registers_info (struct gdbarch *gdbarch,
> +           &nb= sp;            =    struct ui_file *file,
> +           &nb= sp;            =    const frame_info_ptr &frame,
> +           &nb= sp;            =    int regnum,
> +           &nb= sp;            =    bool print_all)
> +{
> +  const int numregs =3D gdbarch_num_cooked_regs (gdbarch);
> +  aarch64_gdbarch_tdep *tdep =3D gdbarch_tdep<aarch64_gdbarch= _tdep> (gdbarch);
> +
> +  if (regnum =3D=3D -1)
> +    {
> +      for (int i =3D 0; i < numregs; i++)=
> +     {
> +       if (i =3D=3D tdep->poe_regnum= )
> +         {
> +           aarch64_= print_poe_register_info (file, i, "por_el0", frame);
> +           continue= ;
> +         }
> +       default_print_registers_info (gd= barch, file, frame,  i, print_all);
> +     }
> +    }
> +  else if (regnum =3D=3D tdep->poe_regnum)
> +    aarch64_print_poe_register_info (file, regnum, &qu= ot;por_el0", frame);
> +  else
> +    default_print_registers_info (gdbarch, file, frame= , regnum, print_all);
> +}
> +
>  /* Implement the "pseudo_register_reggroup_p" tdesc_ar= ch_data method.  */
> 
>  static bool

Instead of adding this gdbarch hook, have you considered using enum
target types=B9 in the feature XML instead? E.g:

<feature name=3D"org.gnu.gdb.aarch64.poe">
  <enum id=3D"perms_enum" size=3D"4">
    <evalue name=3D"---" value=3D"0"/= >
    <evalue name=3D"r--" value=3D"1"/= >
    <evalue name=3D"r-x" value=3D"2"/= >
    <evalue name=3D"r-x" value=3D"3"/= >
    <evalue name=3D"-w-" value=3D"4"/= >
    <evalue name=3D"rw-" value=3D"5"/= >
    <evalue name=3D"-wx" value=3D"6"/= >
    <evalue name=3D"rwx" value=3D"7"/= >
    <!-- Maybe add the other 8 values as "???"?= -->
  </enum>
  <flags id=3D"por_flags" size=3D"8">
    <field name=3D"P0" start=3D"0" en= d=3D"3" type=3D"perms_enum"/>
    <field name=3D"P1" start=3D"4" en= d=3D"7" type=3D"perms_enum"/>
    <field name=3D"P2" start=3D"8" en= d=3D"11" type=3D"perms_enum"/>
    <field name=3D"P3" start=3D"12" e= nd=3D"15" type=3D"perms_enum"/>
    <!-- And so on until P15. -->
  </flags>

  <reg name=3D"por_el0" bitsize=3D"64" type=3D&= quot;por_flags" group=3D"system"/>
</feature>

Note that I haven't tested the above and I'm not sure it would actually
work (or work well).

I see two advantages:

- It works in the "print $por_el0" case too, not only "info = register
  $por_el0". Or does this patch also work with "print $por_e= l0" as well?

- It's less code.

> @@ -4141,6 +4221,10 @@ aarch64_features_from_target_desc (const struct= target_desc *tdesc)
>    features.fpmr =3D (tdesc_find_feature (tdesc, "= org.gnu.gdb.aarch64.fpmr")
>            = ;       !=3D nullptr);
> 
> +  /* Check for POE feature.  */
> +  features.poe =3D (tdesc_find_feature (tdesc, "org.gnu.gdb= .aarch64.poe")
> +           &nb= sp;   !=3D nullptr);
> +
>    return features;
>  }
> 
> @@ -4774,6 +4858,7 @@ aarch64_gdbarch_init (struct gdbarch_info info, = struct gdbarch_list *arches)
>    tdep->gcs_reg_base =3D first_gcs_regnum;
>    tdep->gcs_linux_reg_base =3D first_gcs_linux_regn= um;
>    tdep->fpmr_regnum =3D fpmr_regnum;
> +  tdep->poe_regnum =3D poe_regnum;
> 
>    /* Set the SME register set details.  The pseud= o-registers will be adjusted
>       later.  */

This change and the one above it in aarch64_features_from_target_desc
should be in the previous patch instead.

--
Thiago
(he/him)

=B9 https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.ht= ml#Enum-Target-Types
--_000_AS8PR08MB10099AF828BCAA07C846ED62E9BE82AS8PR08MB10099eu_--