Re: [PATCH] [Arm] Remove dead FPA code

[Luis Machado <luis.machado@arm.com>]

On 10/13/22 10:40, Luis Machado via Gdb-patches wrote:
> 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.

Before I refresh this patch, did you have thoughts on the above?