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

[Pedro Alves <pedro@palves.net>]

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:

....
  <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>


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.