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

[John Baldwin <jhb@FreeBSD.org>]

On 10/4/22 1:43 AM, Luis Machado via Gdb-patches wrote:
> On 10/3/22 20:16, Pedro Alves wrote:
>> On 2022-09-20 1:30 p.m., Luis Machado via Gdb-patches wrote:
>>
>>> diff --git a/gdb/arch/arm.h b/gdb/arch/arm.h
>>> index 36757493406..74a6ba93bc7 100644
>>> --- a/gdb/arch/arm.h
>>> +++ b/gdb/arch/arm.h
>>> @@ -44,11 +44,6 @@ enum gdb_regnum {
>>>      ARM_SP_REGNUM = 13,		/* Contains address of top of stack */
>>>      ARM_LR_REGNUM = 14,		/* address to return to from a function call */
>>>      ARM_PC_REGNUM = 15,		/* Contains program counter */
>>> -  /* F0..F7 are the fp registers for the (obsolete) FPA architecture.  */
>>
>> Shouldn't we leave behind a comment explaining why there's a hole between 15 and 25?
> 
> I pondered about this a bit more, and I think we should close the gap and bring CPSR down to
> 16, its "natural" position. It is what linux uses for user_regs as well, in gdb/arch/arm-linux.h:
> 
> /* The index to access CSPR in user_regs defined in GLIBC.  */
> #define ARM_CPSR_GREGNUM 16
> 
>>
>> IIRC the numbers can't be changed since we need to handle the case when the target
>> doesn't send an xml tdesc, so it'd be good to help future readers understand why
>> there's a hole.
> 
> That's correct. Though a 32-bit Arm target that doesn't support XML descriptions these days is not very
> common. I haven't seen one in a while.
> 
> I'm willing to declare old 32-bit Arm targets that don't send XML target descriptions back as unsupported.
> 
> To that effect, I suppose we should add a note to make it more explicit.
> 
> More below.

FWIW, the GDB stub in FreeBSD's kernel does not use XML target descriptions
for any architectures, but it also only tends to do GPRs and not any floating
point.  For 32-bit ARM it does not report any register values higher than
number 15 (PC), so it would not be affected by changing this.

Do you know if LLDB supports floating-point registers on 32-bit arm as well?
The register numbers in the 'g' packet are effectively part of the protocol
shared between the two, so might be worth coording with lldb folks as well if
they support FPA?

-- 
John Baldwin