From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id DF36F3858CDA for ; Wed, 5 Oct 2022 16:57:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF36F3858CDA Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7496123A; Wed, 5 Oct 2022 09:58:03 -0700 (PDT) Received: from [10.57.36.39] (unknown [10.57.36.39]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 79CC63F67D; Wed, 5 Oct 2022 09:57:55 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2022 17:57:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] [Arm] Remove dead FPA code Content-Language: en-GB To: John Baldwin , Luis Machado , Pedro Alves , gdb-patches@sourceware.org, David Spickett References: <20220920123012.189293-1-luis.machado@arm.com> <73479562-ab47-dfbf-aadc-7a2203c0f0e4@FreeBSD.org> <56653c70-593a-4b8d-ddf7-52f7dd0608f7@arm.com> <1946bc74-8270-23c4-9483-702b9dbc03de@FreeBSD.org> <3cb2d818-83e8-4e2d-5e1b-9b555d1a2217@arm.com> From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3495.8 required=5.0 tests=BAYES_00, BODY_8BITS, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2022 16:57:59 -0000 On 05/10/2022 17:48, John Baldwin wrote: > On 10/5/22 1:26 AM, Luis Machado wrote: >> On 10/4/22 22:36, John Baldwin wrote: >>> On 10/4/22 10:43 AM, Luis Machado wrote: >>>> On 10/4/22 18:08, John Baldwin wrote: >>>>> 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. >>>> >>>> Does it care about CPSR and/or XPSR? Could you please give it a try >>>> to see if the defaults would suit it just fine? >>> >>> Hmm, I misread and it does care about CPSR for the current thread.  The >>> relevant code is here (From >>> https://cgit.freebsd.org/src/tree/sys/arm/arm/gdb_machdep.c): >>> >>> void * >>> gdb_cpu_getreg(int regnum, size_t *regsz) >>> { >>> >>>       *regsz = gdb_cpu_regsz(regnum); >>> >>>       if (kdb_thread == curthread) { >>>           if (regnum < 13) >>>               return (&kdb_frame->tf_r0 + regnum); >>>           if (regnum == 13) >>>               return (&kdb_frame->tf_svc_sp); >>>           if (regnum == 14) >>>               return (&kdb_frame->tf_svc_lr); >>>           if (regnum == 15) >>>               return (&kdb_frame->tf_pc); >>>           if (regnum == 25) >>>               return (&kdb_frame->tf_spsr); >>>       } >>> >>>       switch (regnum) { >>>       case 4:  return (&kdb_thrctx->pcb_regs.sf_r4); >>>       case 5:  return (&kdb_thrctx->pcb_regs.sf_r5); >>>       case 6:  return (&kdb_thrctx->pcb_regs.sf_r6); >>>       case 7:  return (&kdb_thrctx->pcb_regs.sf_r7); >>>       case 8:  return (&kdb_thrctx->pcb_regs.sf_r8); >>>       case 9:  return (&kdb_thrctx->pcb_regs.sf_r9); >>>       case 10:  return (&kdb_thrctx->pcb_regs.sf_r10); >>>       case 11:  return (&kdb_thrctx->pcb_regs.sf_r11); >>>       case 12:  return (&kdb_thrctx->pcb_regs.sf_r12); >>>       case 13:  stacktest = kdb_thrctx->pcb_regs.sf_sp + 5 * 4; >>>             return (&stacktest); >>>       case 15: >>>             /* >>>              * On context switch, the PC is not put in the PCB, but >>>              * we can retrieve it from the stack. >>>              */ >>>             if (kdb_thrctx->pcb_regs.sf_sp > KERNBASE) { >>>                 kdb_thrctx->pcb_regs.sf_pc = *(register_t *) >>>                     (kdb_thrctx->pcb_regs.sf_sp + 4 * 4); >>>                 return (&kdb_thrctx->pcb_regs.sf_pc); >>>             } >>>       } >>> >>>       return (NULL); >>> } >>> >>> The 'kdb_thread == curthread' case is when a thread enters the >>> debugger due >>> to a crash or breakpoint, etc.  We do return CPSR for that thread, >>> but we do >>> not return it for other threads.  It looks like we do also know the >>> FPA register >>> size so that we return enough "xx" bytes in the 'g' reply to mark the FP >>> registers as unavailable so that we can return the value of CPSR in >>> the 'g' >>> reply. >>> >>>   From https://cgit.freebsd.org/src/tree/sys/arm/include/gdb_machdep.h: >>> >>> #define    GDB_NREGS    26 >>> #define    GDB_REG_SP    13 >>> #define    GDB_REG_LR    14 >>> #define    GDB_REG_PC    15 >>> >>> static __inline size_t >>> gdb_cpu_regsz(int regnum) >>> { >>>       /* >>>        * GDB expects the FPA registers f0-f7, each 96 bits wide, to >>> be placed >>>        * in between the PC and CSPR in response to a "g" packet. >>>        */ >>>       return (regnum >= 16 && regnum <= 23 ? 12 : sizeof(int)); >>> } >>> >>> NetBSD's kernel seems to have similar knowledge: >>> >>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/include/db_machdep.h?rev=1.28&content-type=text/x-cvsweb-markup&only_with_tag=MAIN >>> >>> >>> (The kgdb bits near the bottom) >>> >>> Linux's kernel also seems to maybe hardcode this knowledge as well: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/kernel/kgdb.c#n21 >>> >>> >> >> 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 can certainly deal with updating FreeBSD.  I can try to find someone > over in NetBSD > land.  Honestly, the simplest approach might be to start exporting XML > from the > kernel.  However, an even simpler workaround for now might be having a > knob that > can be set for older debugger binaries that still places CPSR at the old > register > number vs the newer one. > IMO, exporting an XML description of the register set(s) available is certainly the right way forward. In fact, I'd strongly suggest we leave the existing packet formats as-is for now and add support for XML to the relevant kernels. At some point then gdb (and LLDB) can simply stop working with older kernel versions that don't do it the 'right' way. R.