From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70071.outbound.protection.outlook.com [40.107.7.71]) by sourceware.org (Postfix) with ESMTPS id 1E6AC3851A88 for ; Tue, 4 Oct 2022 08:44:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E6AC3851A88 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=d/7SHhJ4ndOGUpomxH9gtdUrVdm6fYAx7lN+GJTa+2+lgWt2NwZb2bqfgofyuBlKv2ehsDSsoWvY+axL/cFP3ZhzdLNIUJHPPlefSVe6eL530klYQTP4wUu3U2LAMthqb10di5KstcswyUnq740O07dT/POL22AQB/mQhe20x6tN7AiT/y/TJGRQxYsS+lEmXNw/BB7eW8uV9U1e83+yODhbXsUFqtfZ+yqtJs5lMy+oE7v9VFNxTWqwehAcoz8HD39SXKuzllG5C5RI3lVGyLnVXebSoXO+6jAv0j5nD7N7V8K8bb7TQz48s4AIxi8tv/jhHKMeEbAZ5Ni8/oOONA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=8QogkMQQbqz1FaUVCanFX+plADav57y0rnUNltlWeWA=; b=ZMYz23NihDLviLBYN9BdKHDNRWvGLxWgGV6C1X65mzAf6bsPHa8ahwxq3nvX6PzZnW80GYPA6yyPgOzewX/Vr6gLJ386K/fi5NRvbAWvV6c1R4PmCOC2c4u2wV5nXZ+XwdNOVR+gfar9i6VCVl/r2c0E0d+FWzTvMyZ87/J+wv8cq1kamczMfRiqwgotO8PYeHXwYcccl5mWPOVuWAKTlf3j9oCSGejtSoh8Mq+lrjUsKKXIgShEcXFPz5KRsAKdx2NPIjkRw4OyvYlespvHNVZ1R626auEPD5cRqCcuHPdh1gdL5390YjtCCFVjCaDVNiC/XWm14+buHjqYirpaSg== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) 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=armh.onmicrosoft.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]) Received: from AS8PR04CA0166.eurprd04.prod.outlook.com (2603:10a6:20b:331::21) by DU0PR08MB8563.eurprd08.prod.outlook.com (2603:10a6:10:404::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.23; Tue, 4 Oct 2022 08:44:07 +0000 Received: from AM7EUR03FT025.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:331:cafe::14) by AS8PR04CA0166.outlook.office365.com (2603:10a6:20b:331::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.31 via Frontend Transport; Tue, 4 Oct 2022 08:44:07 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT025.mail.protection.outlook.com (100.127.140.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.17 via Frontend Transport; Tue, 4 Oct 2022 08:44:07 +0000 Received: ("Tessian outbound 937eed45f6ed:v128"); Tue, 04 Oct 2022 08:44:07 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 0e0242640b3b0bee X-CR-MTA-TID: 64aa7808 Received: from 02a161f0c4d3.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8BC01DE0-67A8-4442-9C7F-A26D4B8ABA83.1; Tue, 04 Oct 2022 08:44:00 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 02a161f0c4d3.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 04 Oct 2022 08:44:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kUY4Q77iXraNQNr5KDduzbKG1IIhzHo3WaCAzYZO23dzKqaKkK6N6nDtzeALs1qCaeKL7YUt+0jW2wu78JM612/IUSk8ipv/RVTuGOHRglGMnEvMVIu0qDWYMCTzl8J35QRVrWl6s2fJRpOblqDb+31jjHK8kxZR0xv+i966qhHyNuP21WIMcW/MxqtRlTHtg2sidQYL/W0aCeMqMV0J/7bYRNIAgh/b98RmOEU9/cdZJdPfYsI60a9LMYbyc7kqMqWuubrlDE/kgEXYhmDT0i8m9ULVDGmuRf8Vx/Bn9o1LF1F70R2JTZjiQLmlXgNPFsGaDlylRA8AXN75gwtkBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=8QogkMQQbqz1FaUVCanFX+plADav57y0rnUNltlWeWA=; b=GyLxBfUXl+81U5LKT728gqUchp5k5nwqOq1gz1KoCBW8T88CUs8QUqMIRHb7TCKmS5d5nPVFpdCHS8u4CQkJlNn8KTPpUWZw4+jCmyyq2nbGy0NNJjl+KLSKNWYYO278VoP1Y7OaDn9kXqm2aaxbG2ZjSno5DhALzbyPqN0M+BGkZyVlznH//E7wcVR6PIv0355IMFzzPBjsKTU/e2upXKlYrVsBbUp3kNr6OWIcob2uxiOUL9/ERvCAK1DOakZNkC0AlxifXyqwxsO1j7KS6J3hXZYXIS7fFOYaiILwYAT0HRGJJDokjFirBHkH7DQb9VWmwY4pT9yzvKaeQIWK/w== 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 Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by PAVPR08MB9460.eurprd08.prod.outlook.com (2603:10a6:102:316::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.24; Tue, 4 Oct 2022 08:43:54 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094%5]) with mapi id 15.20.5676.028; Tue, 4 Oct 2022 08:43:54 +0000 Message-ID: Date: Tue, 4 Oct 2022 09:43:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] [Arm] Remove dead FPA code Content-Language: en-US To: Pedro Alves , gdb-patches@sourceware.org References: <20220920123012.189293-1-luis.machado@arm.com> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0116.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::32) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|PAVPR08MB9460:EE_|AM7EUR03FT025:EE_|DU0PR08MB8563:EE_ X-MS-Office365-Filtering-Correlation-Id: 5460c43c-5319-4440-0bb8-08daa5e499b9 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: AT1VD7szbjOr09Zrt/66ObQGA93QyOFTM5tz3DrYRROB8XcdHAoR/t/LNGmR7WI9qIJAPwDo17Wlip268xXTi5qa20bwhy9zze4I2UY77OM/OXXN26zwVda8MgEOB2TyT3krjOKA+UxuULZzDWDzDoJIVDQgEcbBbfDKMg4yrvh9C8scqzsur9O1Cb8Xccay7NUX+A3AvYaZkNyM/T3hn3XJxhE0YYO3U2CyF0hwpV2ywJ74jmWiG/8CvduvUjeIBi7R8A6dFzjz8YXwXBpFhnWaLqrINWA8PiVTQYP9/yqZY9U1+6SGe+CN1ttbFBDediPazQ2/ZDY3LZjPWzUa8Ik4dzu/A9QImdTMMi+7u/lA5KQ8Z1ys7iI+IbPAgZri1C3eVAvRqQX/pL9PCHSL/UI72vPHQ9ax4g/d/B5Ni4p80DG5y8HVgOco8zZO7m99tG3YlqlVAPt06UX6OobRr0ywzB4Dp8brZ8DgcvB+4tAcrpXhdygkGyYDDYR2usk+Uivdao1jl7F6VKYziPT2oHIIPVH4orVIcz08bp2bmd4KR4/zt2UnnZasPaBdliI0lKkFTGIS0gCeXrtXOkUu3zdEJ1hXZMdMPOkRWZeHQkgHJyYarNdu72JWBIDtI88i6zXUHFw0Ch8pppHV6HQO6Ofq2PynZfpQXcg4yvKkTok= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB3919.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(136003)(376002)(39860400002)(396003)(366004)(346002)(451199015)(31686004)(8936002)(41300700001)(6486002)(2906002)(38100700002)(478600001)(83380400001)(36756003)(66946007)(6666004)(66556008)(66476007)(186003)(5660300002)(6512007)(26005)(8676002)(31696002)(86362001)(2616005)(53546011)(316002)(6506007)(44832011)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9460 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT025.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 20cd6b38-4e46-44df-9bb7-08daa5e49124 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: b2kb3C27V3UrU2R2f/4VgMoD0OI7ITf+YTuQ/g6eb0zHaBiTKIEJ7FxGNTUXXjq0DV5oN5/dCYgrQln60mK36viP3dqh65C1ZxxtRte5kFfU2L5STr77amwWNagJghCbpCPjoMdYpQmdDJLT3Oizo+umy15jU+HUZr6ufbl7D2T0taCIvuQZuKeQyUI0VZ4oEaf4jJYli9naAnGDNAF+WgD7Ba9ShHgVdXi9SOg3kBL2Zr82OXxGWAZtPkkJHhx+N8V4nf1CL478CHZNHgEtiW8Ic231fU7wBQNbab3BnlXAelXtiXl76dccYR5wBedQOai5GieDlx8MV//nplv1TdgPqvQfwlQqKUB+kvC8cYxtS1+gIWDFf9QdNfqWobadJAiMQCYE24TiEhwEcAObHiR2yTkykWfPsPURsK854d71Z+plLW6wbIgS8jPl4cNN0J2od3+mtrWlnOL06S1tUkxVKFrmX90tbjA1mc2pGbCPs5AVvChmnV1suM+Wt50F/oh6Dvtkeg7O6IfWk09nP76v77hcuV0/hAHS6hA9REFJ25IuXuWDr3wmgdecWr3yOoNrZHmPWcJddalK2chzpFDMuMmwJsrf42lToCMz+Ve10czmaICh/LXKitYOJoKog+3ZrvIP/fLoXhKCEf9vLUtFJ3gEPqDchULy7JtpFfQp/Bl6+Ks+yi4zQwM7E2froEhDqqYJt2qUW6fw4/q06anL+G8dAFiJw5aiM3qFm4WSQGkKRkJ9rvzzbJEyjXH9FLIMljZOzB5153U4Y4IZMhfz/Xu29QRL3xwV+s3H70dw4T+BHO4eZj8IpFMvJ9Au X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230022)(4636009)(396003)(346002)(376002)(39860400002)(136003)(451199015)(46966006)(40470700004)(36840700001)(336012)(186003)(70206006)(8676002)(70586007)(6486002)(44832011)(2616005)(2906002)(82740400003)(26005)(53546011)(478600001)(5660300002)(6506007)(31696002)(36756003)(40460700003)(86362001)(356005)(40480700001)(6666004)(8936002)(41300700001)(83380400001)(82310400005)(81166007)(36860700001)(6512007)(47076005)(31686004)(316002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2022 08:44:07.5733 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5460c43c-5319-4440-0bb8-08daa5e499b9 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT025.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8563 X-Spam-Status: No, score=-13.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2022 08:44:14 -0000 On 10/3/22 20:16, Pedro Alves wrote: > On 2022-09-20 1:30 p.m., Luis Machado via Gdb-patches wrote: > >> diff --git a/gdb/arch/arm.h b/gdb/arch/arm.h >> index 36757493406..74a6ba93bc7 100644 >> --- a/gdb/arch/arm.h >> +++ b/gdb/arch/arm.h >> @@ -44,11 +44,6 @@ enum gdb_regnum { >> ARM_SP_REGNUM = 13, /* Contains address of top of stack */ >> ARM_LR_REGNUM = 14, /* address to return to from a function call */ >> ARM_PC_REGNUM = 15, /* Contains program counter */ >> - /* F0..F7 are the fp registers for the (obsolete) FPA architecture. */ > > Shouldn't we leave behind a comment explaining why there's a hole between 15 and 25? I pondered about this a bit more, and I think we should close the gap and bring CPSR down to 16, its "natural" position. It is what linux uses for user_regs as well, in gdb/arch/arm-linux.h: /* The index to access CSPR in user_regs defined in GLIBC. */ #define ARM_CPSR_GREGNUM 16 > > IIRC the numbers can't be changed since we need to handle the case when the target > doesn't send an xml tdesc, so it'd be good to help future readers understand why > there's a hole. That's correct. Though a 32-bit Arm target that doesn't support XML descriptions these days is not very common. I haven't seen one in a while. I'm willing to declare old 32-bit Arm targets that don't send XML target descriptions back as unsupported. To that effect, I suppose we should add a note to make it more explicit. More below. > > >> - ARM_F0_REGNUM = 16, /* first floating point register */ >> - ARM_F3_REGNUM = 19, /* last floating point argument register */ >> - ARM_F7_REGNUM = 23, /* last floating point register */ >> - ARM_FPS_REGNUM = 24, /* floating point status register */ >> ARM_PS_REGNUM = 25, /* Contains processor status */ >> ARM_WR0_REGNUM, /* WMMX data registers. */ >> ARM_WR15_REGNUM = ARM_WR0_REGNUM + 15, >> @@ -67,7 +62,6 @@ enum gdb_regnum { >> ARM_FP_REGNUM = 11, /* Frame register in ARM code, if used. */ >> THUMB_FP_REGNUM = 7, /* Frame register in Thumb code, if used. */ >> ARM_LAST_ARG_REGNUM = ARM_A4_REGNUM, >> - ARM_LAST_FP_ARG_REGNUM = ARM_F3_REGNUM >> }; >> > > >> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c >> index ead9bbf46c5..b33a53612a6 100644 >> --- a/gdb/arm-tdep.c >> +++ b/gdb/arm-tdep.c >> @@ -134,8 +134,6 @@ static struct cmd_list_element *showarmcmdlist = NULL; >> static const char *const fp_model_strings[] = >> { >> "auto", >> - "softfpa", >> - "fpa", >> "softvfp", >> "vfp", >> NULL >> @@ -226,9 +224,7 @@ static const char *const arm_register_names[] = >> "r4", "r5", "r6", "r7", /* 4 5 6 7 */ >> "r8", "r9", "r10", "r11", /* 8 9 10 11 */ >> "r12", "sp", "lr", "pc", /* 12 13 14 15 */ >> - "f0", "f1", "f2", "f3", /* 16 17 18 19 */ >> - "f4", "f5", "f6", "f7", /* 20 21 22 23 */ >> - "fps", "cpsr" }; /* 24 25 */ >> + "cpsr" }; /* 25 */ >> > > Don't the array indexes here need to match the register numbers? The "cpsr" string > above is no longer at index 25 after this change. That's right. This needs to be adjusted. We don't use this array to name cpsr though. We do it explicitly as: if (is_m) valid_p &= tdesc_numbered_register (feature, tdesc_data.get (), ARM_PS_REGNUM, "xpsr"); else valid_p &= tdesc_numbered_register (feature, tdesc_data.get (), ARM_PS_REGNUM, "cpsr"); We may still try to return its name. I've fixed this locally. Thanks for spotting it. > > >> -/* For backward-compatibility we allow two 'g' packet lengths with >> - the remote protocol depending on whether FPA registers are >> - supplied. M-profile targets do not have FPA registers, but some >> - stubs already exist in the wild which use a 'g' packet which >> - supplies them albeit with dummy values. > > So this patch is also removing support for these M-profile targets covered by > that last sentence. Are we OK with that? > > I haven't seen any of these targets "in the wild" or received reports of broken sessions. Most of these were debugging stubs and probe software, but they have since migrated to the XML scheme or fell in disuse. It is a maintenance burden for the port, and there is no easy way to test it, as it is mostly a guess if it is working properly. With that said, I'm OK with deprecating the g packet guesses for 32-bit Arm. >> - The packet format which >> - includes FPA registers should be considered deprecated for >> - M-profile targets. */ >> - >> -static void >> -arm_register_g_packet_guesses (struct gdbarch *gdbarch) >> -{ >> - arm_gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); >> - >> - if (tdep->is_m) >> - { >> - const target_desc *tdesc; >> - >> - /* If we know from the executable this is an M-profile target, >> - cater for remote targets whose register set layout is the >> - same as the FPA layout. */ >> - tdesc = arm_read_mprofile_description (ARM_M_TYPE_WITH_FPA); >> - register_remote_g_packet_guess (gdbarch, >> - ARM_CORE_REGS_SIZE + ARM_FP_REGS_SIZE, >> - tdesc); >> - >> - /* The regular M-profile layout. */ >> - tdesc = arm_read_mprofile_description (ARM_M_TYPE_M_PROFILE); >> - register_remote_g_packet_guess (gdbarch, ARM_CORE_REGS_SIZE, >> - tdesc); >> - >> - /* M-profile plus M4F VFP. */ >> - tdesc = arm_read_mprofile_description (ARM_M_TYPE_VFP_D16); >> - register_remote_g_packet_guess (gdbarch, >> - ARM_CORE_REGS_SIZE + ARM_VFP2_REGS_SIZE, >> - tdesc); >> - /* M-profile plus MVE. */ >> - tdesc = arm_read_mprofile_description (ARM_M_TYPE_MVE); >> - register_remote_g_packet_guess (gdbarch, ARM_CORE_REGS_SIZE >> - + ARM_VFP2_REGS_SIZE >> - + ARM_INT_REGISTER_SIZE, tdesc); >> - >> - /* M-profile system (stack pointers). */ >> - tdesc = arm_read_mprofile_description (ARM_M_TYPE_SYSTEM); >> - register_remote_g_packet_guess (gdbarch, 2 * ARM_INT_REGISTER_SIZE, tdesc); > > And what about all these other non-FPA guesses? Do you really mean to drop them? > More recently we've added two new guesses for MVE and M-profile system registers, but it doesn't make sense to do so, as these features are advertised as XML already. So in my opinion, we should drop the g packet guesses completely and rely solely on XML descriptions. >> - } >> - >> - /* Otherwise we don't have a useful guess. */ >> -} >> - >> /* Implement the code_of_frame_writable gdbarch method. */ >> >> static int >