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

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

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.

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.

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.

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.