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

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

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:
> 
> ....
>    <reg name="pc" bitsize="32" type="code_ptr"/>
> 
>    <!-- The CPSR is register 25, rather than register 16, because
>         the FPA registers historically were placed between the PC
>         and the CPSR in the "g" packet.  -->
>    <reg name="cpsr" bitsize="32" regnum="25"/>
> </feature>
> 

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