From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C648EC433FE for ; Wed, 5 Oct 2022 16:58:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zHcdnISVTdevMuUcModN01Wl2o9BAOEZNiMoFPunG6o=; b=3EMPVwPJJNFW24 OliFOG/YS+ZtxQR3Hurs29b2H981pZ7GPq1Zjp9QdXwj6OFRxPTubxTpdukNjKmcf5BM/EJHawE5h oriSLC6qn2AqM6Mlc+hkkCvL2R0UZ6Oxhgn8B9W9AHWfJziHE0UgT+Zu06m3hDkCuD8fhP2/30FW2 Cr/UJFm93SkG/EjPWkCopIaSbccm5AuHXW2KVJRRaLhMXUOu6fIJpg/x9e6QD+5+Qv2xwGHxFWLax oVbKUBGUAOSeTHDejZYPduUNMNVMrNmJVUyNYcsvcDbaYv7vCNGYGZ84iDavRfjIrJyhO+3UaUiA/ OhtTCH3wuoz6s0x9BXnQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1og7hT-00FMHf-G9; Wed, 05 Oct 2022 16:56:51 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1og7hQ-00FLLI-Nm for linux-arm-kernel@lists.infradead.org; Wed, 05 Oct 2022 16:56:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZPw14OHq/SNlnaWYvaasUkJA59UZnqLnrBjr/lo5gHo=; b=zaqSiJP5SP0yMF+06BdQUmk6p3 udqgcXtpjD4xWgEA9tiIam395AZysEIKD5q38mA5cmDJv22/thy4UWYJouGICXZFqozg36vN3RCDU 3OnvQ0V5t2LUmQWbfT7Jks58sH42DD2zzryavZILplt4nSyvqc/MtljIqTa0yk9ZxKSXuu4GG7t5Q kEzD8VjpnR7MW1umPdhsERew3v2hyfbMb8E8K2KrA5LxvpUPDUZuGKZJVm5vc43JV8he48glEmBby CK7OR2pXW0Q+OG8FBHxRh280aRd2QxsMoBZ6jKszBmav0nEHw3HIY1QFgis9//44va/rX81bVapYO k2Jai1CA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:34596) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1og7fL-0000lg-8w; Wed, 05 Oct 2022 17:54:39 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1og7fK-0005VT-4A; Wed, 05 Oct 2022 17:54:38 +0100 Date: Wed, 5 Oct 2022 17:54:38 +0100 From: "Russell King (Oracle)" To: Luis Machado Cc: linux-arm-kernel@lists.infradead.org Subject: Re: RFC: FPA support removal from gdb and its impact on kgdb Message-ID: References: <5b0d81f2-00ed-cf3c-8869-420326595e0a@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5b0d81f2-00ed-cf3c-8869-420326595e0a@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221005_095649_079902_F8321518 X-CRM114-Status: GOOD ( 26.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 05, 2022 at 04:03:04PM +0100, Luis Machado wrote: > Hi, > > Following the removal of Arm FPA support from GCC in ~2012, I'm pursuing the same for gdb [1]. > > We should be able to remove mostly everything from gdb, but there is a small portion of code that > deals with targets (like kgdb) that don't expose their register sets through XML. This code in gdb > attempts to detect the register set based on the size of the register buffer ('g' remote packet). > > The problem is that CPSR was historically hardcoded to register 25 to make way for the FPA registers in the middle. > > From arch/arm/kernel/kgdb.c: > > struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = > { > { "r0", 4, offsetof(struct pt_regs, ARM_r0)}, > { "r1", 4, offsetof(struct pt_regs, ARM_r1)}, > { "r2", 4, offsetof(struct pt_regs, ARM_r2)}, > { "r3", 4, offsetof(struct pt_regs, ARM_r3)}, > { "r4", 4, offsetof(struct pt_regs, ARM_r4)}, > { "r5", 4, offsetof(struct pt_regs, ARM_r5)}, > { "r6", 4, offsetof(struct pt_regs, ARM_r6)}, > { "r7", 4, offsetof(struct pt_regs, ARM_r7)}, > { "r8", 4, offsetof(struct pt_regs, ARM_r8)}, > { "r9", 4, offsetof(struct pt_regs, ARM_r9)}, > { "r10", 4, offsetof(struct pt_regs, ARM_r10)}, > { "fp", 4, offsetof(struct pt_regs, ARM_fp)}, > { "ip", 4, offsetof(struct pt_regs, ARM_ip)}, > { "sp", 4, offsetof(struct pt_regs, ARM_sp)}, > { "lr", 4, offsetof(struct pt_regs, ARM_lr)}, > { "pc", 4, offsetof(struct pt_regs, ARM_pc)}, > { "f0", 12, -1 }, > { "f1", 12, -1 }, > { "f2", 12, -1 }, > { "f3", 12, -1 }, > { "f4", 12, -1 }, > { "f5", 12, -1 }, > { "f6", 12, -1 }, > { "f7", 12, -1 }, > { "fps", 4, -1 }, > { "cpsr", 4, offsetof(struct pt_regs, ARM_cpsr)}, > }; > > Changing gdb to use CPSR as register 16 (not 25) would potentially break Linux's kgdb (and also > *BSD's kgdb). Unless these -1 offsets get handled in a special way and the f registers never > make their way to the register buffer in the 'g'/'G' packets. Looking at the code in the file you mention above, specifically dbg_get_reg() which is immediately below the table you quoted above, we see that an attempt to get the FPA registers (with an offset of -1) will result in a value of all-zeros returned. If we look further into the gdbstub that the kernel uses (in kernel/debug/gdbstub.c) we find: void pt_regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs) { int i; int idx = 0; char *ptr = (char *)gdb_regs; for (i = 0; i < DBG_MAX_REG_NUM; i++) { dbg_get_reg(i, ptr + idx, regs); idx += dbg_reg_def[i].size; } } So, all registers are fetched to a block of memory (defined by the first argument to this function). This is called from gdb_get_regs_helper() and places the register values in a static-global gdb_regs array. And then we have: /* Handle the 'g' get registers request */ static void gdb_cmd_getregs(struct kgdb_state *ks) { gdb_get_regs_helper(ks); kgdb_mem2hex((char *)gdb_regs, remcom_out_buffer, NUMREGBYTES); } So, it looks to me like the stub returns the registers as a block of hex, and removing the FPA registers _will_ break the stub. Given this, and this is a fundamental interface between two different pieces of software, I fail to see how you can even consider removing support for this - if you remove support from gdb, then later gdb will be unable to debug existing kernels. In kernel-land, we have a rule: don't break userspace. I think there should also be a rule for userspace: don't break the kernel! -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel