From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2082.outbound.protection.outlook.com [40.107.247.82]) by sourceware.org (Postfix) with ESMTPS id 2CE023857BB5 for ; Thu, 13 Oct 2022 09:41:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CE023857BB5 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=gD4TyqukuLPtRiNVKWkbfScFqrXPCiFkZKSJ+V1sGCUTESIyRoeXWt+PMjr4jDn9lqADG5ZXCHZvqdkqRpXCzaDqOJsa3XaB0RpzmuzHj/xCzZ90wWc7wYq6CsDn/LTFfnV6hK3mimQecxGDyYYprtoOihZ69wLNvAK8grFTR/B8ZVDfGbaBIV9E5Hf9e03uFbdvdUEW9dzY2n4lMeRa9jl3m9iETh22IibVm1G7xNihK91Cr21aqp/jW/F5B0MH9NtO/zQd7jRZH7YLk3FOl6do3b5tNj2d8tvHUhXsF/+5OqNZgSBcp7mdHaMq2F1spqrHvjUI3l1nhwWdJbmJhw== 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=IaCw+IY9Nbt6kYTg643m/PvfycMbUgf+Zws61iIVTbE=; b=Br+WDVPJrzkyltYSpIX4xc2h6Srqp9q+9+YvhALvfJWu1mMgF+s/3QqMtESYOIYDGEjWGdf3N/AfPDHtmuIzWCA/oxiL58T9d+MvB0cqWIgVSECtORxV7ifaJ9/vcdPprslCaRVSVW9Ttq5LjFzmzE5nJZbZ1OG0NrrcTOXTS2qz+Y13OJRNjzyu2GljY9woSTzrif584jZ96kuhf0cWFtvb5c+JVpmWXUqn4VI0wNoAvsJLfR83HMISufRfRUuGTYYWeG+tVF0vHt9B8GtPg0OPhRgBhDi5T2EtFVgADcJO08196a10o8q90PzSh26HEvK+wkUpTRs+15oGtpog4w== 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 DUZPR01CA0061.eurprd01.prod.exchangelabs.com (2603:10a6:10:3c2::19) by DBBPR08MB5993.eurprd08.prod.outlook.com (2603:10a6:10:1f4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.26; Thu, 13 Oct 2022 09:40:56 +0000 Received: from DBAEUR03FT036.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:3c2:cafe::c8) by DUZPR01CA0061.outlook.office365.com (2603:10a6:10:3c2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.26 via Frontend Transport; Thu, 13 Oct 2022 09:40:56 +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 DBAEUR03FT036.mail.protection.outlook.com (100.127.142.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.20 via Frontend Transport; Thu, 13 Oct 2022 09:40:56 +0000 Received: ("Tessian outbound 7761be2ecf00:v128"); Thu, 13 Oct 2022 09:40:56 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: f2a6c9d2bb9fe453 X-CR-MTA-TID: 64aa7808 Received: from 0854e1f7e4d6.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B6FFC081-29EA-4989-A648-4824FC7F8583.1; Thu, 13 Oct 2022 09:40:47 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0854e1f7e4d6.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 13 Oct 2022 09:40:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wp04HVosDnyHRm+/ZWVORmG7HuHUGqeg5FXpKYfbq30oZxxEp4hxTd7kMyNXnIwakoiG8ntwwoiKlFcWjPm+PBqv+H/FAGWNn12V28KNQ1R6bAn8K6biA5R009B8dFX0ko4q6WNTA4v8ihChim5Gyiq1WmGye3+j0qeuab57+vSNS8GDoUc94I0qo5ZnhDCGFqPrFbrgm0Ed244U2qHz7XiKbxl5tVUY4ednKETBXO0RZigHyTrzyfX+RiRLPJJtIPdQjYQCp6M4EwHeQmN3MAn+lLt4jZUnNLVDNsaSYzNJLOAu/EbkmAQbCtPRQ1aqIHyzWenkh+ixu9oyfjMPFA== 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=IaCw+IY9Nbt6kYTg643m/PvfycMbUgf+Zws61iIVTbE=; b=PeCkd+F7S3rT07D0zlcD3VzSEefZRdNdOItWc+LLbgm1/Ue4ZWWvI78x3PsfRhnqSIiDPRuOAbnBzL1BOwLv9TaLykO9kb0LCYxajHGlfGmO3PMO8WctiVUzKHzyoWYlGNU0nW2XS6sKMld8Ay4rIXr3dxEju9SkSUTFueEMVpuuyY8KpVMjhO6nGw/FywNjU4rTFbS5XoXKkMH8kWYJ3LMlej3ixbhTDKcLaC9MHaqkPESGR7vju4Zh8qd5v+Quh9VKToz9x5QlCBKvHigw2xCxDgO56dzCo5NBKeD97IriqbulracNonwMmJth4Id31Xjf+kEVZwXFwa3g4y9k4w== 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 PA4PR08MB6285.eurprd08.prod.outlook.com (2603:10a6:102:e0::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.26; Thu, 13 Oct 2022 09:40:44 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bbeb:a49e:d969:5d2]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bbeb:a49e:d969:5d2%6]) with mapi id 15.20.5709.021; Thu, 13 Oct 2022 09:40:43 +0000 Message-ID: Date: Thu, 13 Oct 2022 10:40:39 +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 , John Baldwin , gdb-patches@sourceware.org, David Spickett References: <20220920123012.189293-1-luis.machado@arm.com> <73479562-ab47-dfbf-aadc-7a2203c0f0e4@FreeBSD.org> <56653c70-593a-4b8d-ddf7-52f7dd0608f7@arm.com> <1946bc74-8270-23c4-9483-702b9dbc03de@FreeBSD.org> <3cb2d818-83e8-4e2d-5e1b-9b555d1a2217@arm.com> <1003e65d-50fe-8aed-4d98-d06833d27011@palves.net> <42083a0b-9723-8bde-470a-247fbb0740eb@palves.net> From: Luis Machado In-Reply-To: <42083a0b-9723-8bde-470a-247fbb0740eb@palves.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR03CA0005.eurprd03.prod.outlook.com (2603:10a6:208:14::18) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|PA4PR08MB6285:EE_|DBAEUR03FT036:EE_|DBBPR08MB5993:EE_ X-MS-Office365-Filtering-Correlation-Id: 99aa5fdc-ddb9-433e-d73f-08daacff0773 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: 2TfbYgK7TlNkIp528bdKc1j3oKrF3haBt3Eokypa4l2mTofFqB+m2zaXY8fTW7iFQlMGc8oLvV/lV+a9h7Zzm+mbkSAp01fTDBfIXpkBFFOqiBuE67YwpoRemB6bQvhzQ9BeJAV/T2vkLWSFGh4516kYnG1hr1LkIHpdRQVzNz+HF3IS4tMy3xl0j1qRouF05Yo2gP0dLczQi0W/5SF3Acx6QWd7ALEqeeCpYpUV2PqRBj1g5t0IJzLpyzNOgekspzItayXs02ltcv0Bj0PMFW2TCRfNVlbgrI+qFg4josMLPBOGgHfN3YSGGouc/VH8nJUyfDKKSf3FNIEKa+RMrrzIawao0yZeBgSTx2SYE6as6dJzuKB/r2APkrTl9DbRY6RDJqUJUyxYuMIbKzb4SF2moExclIFfAXwRHd34FgmHc9QMWhfgU6ddaMVTfzGSqk1ZzH8o8kcjCb40k7lsF+SqKXdK5OvTrH7ftBKj9SMMhAv53uiGima1TjuPgtoVM+LAqo6VoIxsIS504jdzGxJr3jQzQftmmFPeQEh/+B1C/9cXtKVP5yQXESOF+GhF62A7n6e1mqSyom9p+l6PfD6RszIw4lKrSrucuNI4kel5BE+tSUS2F1Ykgp8hTjlkfheqWsWhcmL8XxfMrF9xteOuodJDXrc+cqeVymGoyO/nXqPFlCHq0qnZYkDV5s46uMnfz2SVnZmEp76/9lW5fgXhXdlkYWBVbByD5JfP2V9hflHvnrHemfcuZ1xcGiwDQ19wMe+cOVXGArZ6w86Q1sUHrkRGLV0yTaYEVVW1kGiDXlB3cioEBNywnQ4IkCiY 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)(376002)(39860400002)(366004)(136003)(346002)(396003)(451199015)(36756003)(31686004)(66899015)(86362001)(31696002)(44832011)(38100700002)(2906002)(4001150100001)(5660300002)(186003)(2616005)(83380400001)(6506007)(26005)(53546011)(6486002)(478600001)(6512007)(966005)(6636002)(110136005)(66946007)(66556008)(66476007)(316002)(41300700001)(8936002)(6666004)(8676002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6285 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: DBAEUR03FT036.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 4486667a-f367-42d9-6906-08daacfefe83 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pvt4mwEAEoLJUEk3yAXOQR3TabxhQAoyi1ipT2okYrxHLtmX/MPWWh2bXuiVd78iVEIAvppSahyjfq1MfEOd2zBOAbn1W8L5I+J62yORuCQ74YOTrGKiO5CmFtmZA6Z3kH8cbzcu3RnQvPPkt0juIYJ0NUukeu5E7nAemRh+BKosOVLmaBQ73Qc9A8emGuHNG8WnGwA3ATWR2YAvqxYat3N9WXT1WBa7wHXNoZ0tDYYPjZBH/5OmPqoZZm+MmyRIOXPlw+f0z1Whqj5XiJofPabhrRmv7YAjT3Hp8nAMri+0uofv+qtdt8zSi6+F72bo0DVIoX6p3wHF4tu/cADWrD56p+kjUZuWtxcNksF1DRYJ+eEYCB4RS3aULXRv2oO96km0Q7V2TbX9FXEWxY1zA3KkNvT37z2gEm48C+lJ7iHRat/kxzzR3dFnNMCH71XIgBqRRp0bR76XuCK/fctlQDtgahrxoYSKmQxwcmac2YaWiOZqhAs3QTgN91PSrKCbBZTu/zhz+CwiiYEBlWONyCbh211YBM4Oi2vJVnrJORT0/+4H6+NevkcIl1ssq9dnHktwTgQQYvqkEuLGtjuJPjuDuMlR6FQShnE0qd083EK9MegyS2vLig4lEr/YuMhg5B0p/Yyh9/Q+x2ryk4HM9Uyv8floch0/bkfX0ka9SMtDtes1OkZAklIJifouOgNWnWFnlGW/7NVPrtwik+lpZ5917SICs7aEEUQP9UWQtGLzOIjw0Ns0QuPX5DYAxsXJCZ820rtTqfzsGgw5lpU8EN82vroV0OQ5u5B5P+cULnBJ/dCaqympc8g2lzp1ukzBxQkpvFK54n1HO+QRytO+pQ== 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)(136003)(396003)(376002)(346002)(39860400002)(451199015)(36840700001)(40470700004)(46966006)(81166007)(66899015)(316002)(6512007)(2616005)(82310400005)(36860700001)(40480700001)(8676002)(83380400001)(53546011)(4001150100001)(2906002)(82740400003)(36756003)(336012)(41300700001)(26005)(110136005)(356005)(6636002)(6506007)(44832011)(40460700003)(31686004)(8936002)(6666004)(5660300002)(186003)(966005)(31696002)(6486002)(86362001)(70586007)(47076005)(478600001)(70206006)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2022 09:40:56.7860 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99aa5fdc-ddb9-433e-d73f-08daacff0773 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: DBAEUR03FT036.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5993 X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, 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: Thu, 13 Oct 2022 09:41:02 -0000 On 10/13/22 09:29, Pedro Alves wrote: > > > On 2022-10-13 8:23 a.m., Luis Machado wrote: >> On 10/10/22 15:58, Pedro Alves wrote: >>> On 2022-10-05 9:26 a.m., Luis Machado wrote: >>> >>>> Yeah, that's what I was worried about. Register discoveries without XML are not great, and more recently debugging stubs have been >>>> exposing more system registers. Having to consider FPA (which was *removed* 10 years ago from GCC, but fell in disuse before then) is not >>>> acceptable at this point. >>>> >>>> If those debugging stubs want to skip XML, I think it would be reasonable for them to at least update the expected 'g' packet to contain just >>>> the basic registers, with CPSR as 16. >>>> >>>> That might need some coordination. I can coordinate this from the Linux Kernel's side, but I never dealt with the BSD kernels. >>> >>> I'm not seeing much point in this: >>> >>> #1 - If the remote side supplies XML, then the register number doesn't really matter, GDB auto-maps the numbers. >>> >>> #2 - If the remote side doesn't supply XML, then you're just setting up for a world of coordination pain for no benefit. >>> >>> In GDB, to keep things working, we just have to keep the FPA register number hole in place.  That's hardly causing >>> any maintenance burden, IMO.  We just have to have comments in place explaining why we have them. >> >> Based on a recent thread with the Arm Linux Kernel maintainer, he finds it reasonable to make kgdb >> return XML data and to keep a compatibility layer (the g guesses) going for a reasonable amount of >> time, after which we can retire the guesses and drop the code. > > Good. Of course, the Linux kernel isn't going to be the only remote server or stub out there. > No, but most of the probes have been updated to use XML over the years. Yes, there is an unknown list of old probes and hardware out there potentially not using XML. I haven't seen any such issues reported against the GDB bugzilla though, which is good either way. >> >> It is not clear when we'll drop the compatibility layer, but at least we can get some traction towards >> making targets use XML and maybe add some deprecation warning to the g packet guesses. If we keep the code as-is, >> there is no incentive to update targets using old mechanisms. > > Deprecation warnings makes sense to me. Much more user-friendly than flat out removing the guesses without a warning > period, and/or changing the non-XML g/G packet layout. > > The (unwritten) policy for as long as I'm worked on GDB has always been that you don't change the hardcoded g/G packet > layout, ever. You can only grow it. Or use XML. Sure. But no longer required for XML-based data. > > While we can push new versions of tools to switch to XML, the older versions will still be out there. Stubs can > be embedded in devices that aren't going to update easily or at all. Is it a good idea to to cause them pain? IMHO, no. > > Note, for the FPA removal, you should send an email to gdb@ as well, see here for the obsoleting procedure: > > https://sourceware.org/gdb/wiki/Internals%20Obsoleting-code > Do you want that procedure followed completely, including the week waiting? I also seem to recall a different policy, where we deprecate something for a particular release and then remove on the next one. In any case, I've added a NEWS entry. I hardly think anybody would care about FPA. It might even be a bit nostalgic. >> >> GDB talks about FPA as if it were something that existed not long ago, while in fact it was deprecated even before GDB >> started using XML descriptions. But the registers were kept that way and GDB was never updated (supposedly because it needed >> to be compatible with some other tool at the time), leading to other tools copying what GDB was exposing, even though they didn't >> support FPA at all. > > The question is only about the hole in the g/G registers layout. where the FPA registers used to be, and the register numbers > for registers that follow. Nobody is arguing for keeping the FPA support at all, I think. > > Just like we have in gdb/features/arm/arm-core.xml: > > .... > > > > > > Right. That hardcoding in the XML is also not necessary anymore, and could be removed to prevent any further confusion for whoever is reading things. We could handle it more gracefully internally, as opposed to propagating incorrect assumptions to other tools. > > That's all we'd need to do in gdb itself too. Hardly a maintenance burden, IMO, and hardly worth it to break backwards > compatibility with random embedded stubs that are hard or impossible to update, IMO. > Those are little maintenance burdens that are not bad in isolation, but they do add up for the port maintenance overall. >> >> One such example is the Linux Kernel, which added these registers because GDB required them. >> >> So in this case GDB has the potential to influence other tools, and we should strive to keep things clean and updated as much as >> possible. This is an attempt at that. >> > > Sure