From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id 74C2D3858034 for ; Thu, 13 Oct 2022 08:29:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 74C2D3858034 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f41.google.com with SMTP id c7-20020a05600c0ac700b003c6cad86f38so2732010wmr.2 for ; Thu, 13 Oct 2022 01:29:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xziLuxOWQnheNh488aRz+1fcimpIP49MovfuqTc7ePQ=; b=l7v1QVlndaRfhd9+bfMzNMqI2xYueyaJps1JPquvYaqG+M0VD82qg5KC4+rx5jf7XV QpR/S8ai81WL1r4xHX+XGylKLlQIwy3YA0tjFY1GUcYvvf1atET9CKWaOswmFd8SiJ/E LEeBnB1AnNsdvROP6YNlrqTdVvZaDdk+v2rQmc9q7rmVdYZ5homVq4x2NAMFyd2EVJPB vdbQHS5gGUYiF7jID4pQUvbAz4eCBrLaEJBWVg2YhLa0MMAu21/YQuUmAlRj7kvMdyG4 xGP0A1T0+fFOip/UABSv5cfkOxSbQIm0zjnPjaoOCaMdh2YKSLAuRYDZ7RkYgC410rIb /ylQ== X-Gm-Message-State: ACrzQf27FTuM96pJe1N6ItJjoIXPz/GDh3tAcAbeJkFzmyr0z6XYWQXg ROtGNDVfxCc4d7JxRr1CahY= X-Google-Smtp-Source: AMsMyM6fOS/P6u6+MtAjZpDxQrPXuStKFrJHnJBAMLkLmobeJFjL5hnFE+TPQxYrlEgu3GQTCcCh4A== X-Received: by 2002:a1c:4485:0:b0:3c6:75b3:f444 with SMTP id r127-20020a1c4485000000b003c675b3f444mr5614293wma.74.1665649780980; Thu, 13 Oct 2022 01:29:40 -0700 (PDT) Received: from ?IPv6:2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653? ([2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653]) by smtp.gmail.com with ESMTPSA id h19-20020a05600c351300b003b4868eb71bsm3937249wmq.25.2022.10.13.01.29.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 01:29:40 -0700 (PDT) Subject: Re: [PATCH] [Arm] Remove dead FPA code To: Luis Machado , 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> From: Pedro Alves Message-ID: <42083a0b-9723-8bde-470a-247fbb0740eb@palves.net> Date: Thu, 13 Oct 2022 09:29:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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 08:29:50 -0000 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. > > 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. 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 > > 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: .... 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. > > 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.