From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 25C113858C50 for ; Tue, 4 Oct 2022 21:36:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25C113858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4MhrcC666Sz3HNY; Tue, 4 Oct 2022 21:36:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhrcC5G5rz3Kq5; Tue, 4 Oct 2022 21:36:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664919371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8ecsxZEMWbQCScBO8ZzkbehjWSuAiyOyCcUQTX3VpmI=; b=yPj0BmmnGwIEkI85bVURNdZWMpeUm20MNvPbH9Iv9OpMlMkuI0+RncAl60k1QosNVNlCcV WT2rMdJhUcCoJeEO6ZSyALOArP2iitXlQovbITwR1dNSp13Cro7HGGIXSMQegTQBnNA1WL B0zBVlub1DaFEipD1nuKUDlyKrh7uDkZ3WgsHOE7EfNFGhBxuYMT6OgHCcy4dal/udedZM 2g6vPOpAP4h3mxn7E1VWCXf0b2r5W11P90nFy2r3SKZXswhbUnwveNQhxD28j7gjglrE5g 5f/8/qfcX005zjGJKslo4TygevD3Yk+SDjnsxq1txtTLboJcbxY6ZUuZN4m88g== Received: from [IPV6:2601:648:8684:ad0:c138:fd94:ebf2:bb32] (unknown [IPv6:2601:648:8684:ad0:c138:fd94:ebf2:bb32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MhrcC10hSz1Nsf; Tue, 4 Oct 2022 21:36:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <1946bc74-8270-23c4-9483-702b9dbc03de@FreeBSD.org> Date: Tue, 4 Oct 2022 14:36:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Content-Language: en-US To: 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> From: John Baldwin Subject: Re: [PATCH] [Arm] Remove dead FPA code In-Reply-To: <56653c70-593a-4b8d-ddf7-52f7dd0608f7@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664919371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8ecsxZEMWbQCScBO8ZzkbehjWSuAiyOyCcUQTX3VpmI=; b=W+FUnWrVcO7R7s4XMNXSMzf3eyTPPbLQFU8zmari7uFmyZHLa0sMsMAUnYmbeSmG5uwJOt 1r9WVANm5haKEkHiC1/ITpKGO1r0az9ig6VB8eL2CH++36ByyZ0Wlm87OhWzsie9OkYFPJ bM8R3JGQ9cqD+ouj7Usf4mjmJRP7nFVN/J3uwhQ4Oe/LE/9MEmcNhaSDerDx3IzrOJKNc6 OYUYecngcfdztkYNMFWPwIeU/CIRbqdAX6smoyygU+VzIDgGYajjk5f8KceDaXLWsVms00 N4s2kOylaztQoY+WlWNSY8yUpN2RwUW3dxV60syTcm7DM7uAAkKyhgBSFR5XOw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664919371; a=rsa-sha256; cv=none; b=TOp0X5PhXPxfLis3nAyCurViXMTyyRUs46j21Qgbriq544yZSzKhrFanAY3PEFenTKcyNx 3OO8Lr4MCJrbKDqSsQFzqkUVczn0ozLa5YK6LbLXtygMGtcMa5iV4rvkY5/L052nNudFqX 6uqGMAYqhZMGfsq28Un3XvextYwGgWg7fkYT87FqQNtyPunhaCvtDvw4rwqFEZEACUSaDn EDdp1JgRl8efg51O/Ogq2apeC02dj29RRckMXcKC8Ev207s419/T7t/14ZTGJqUkjJEVxh VPOOTFmv0e8YC/lVrzd4/W5ZwaN1isg0PyekVJOqBjHaJdfxFVif9lmG1mQTJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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: Tue, 04 Oct 2022 21:36:13 -0000 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 -- John Baldwin