From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id B06023858D33 for ; Tue, 27 Feb 2024 23:07:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B06023858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B06023858D33 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2610:1c1:1:606c::19:2 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1709075226; cv=pass; b=a9rV2CZUnACJNnmwdr1laFTcLySWeDG/yO86zSBwbcWw4ZJTqkEa2pwo84UoRb9c9I1Rrw683UEmpZcC5IsTjzcHbPc2F8wewXXl3oyLkpzR7CbXQGPgZfgSHLB2YRkMTGSe5Xtsmgn/5yrOq+RSE4pSPkLdOE0v/AQHWnVd14s= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1709075226; c=relaxed/simple; bh=mWzGc9KiE3rW/C4ZMK3STIvraW+PKUZ0PmqaPvOb3cY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JPM+8DN//4vvaWwSuCWWU0PJzWidoJWqoMgZVI/e3drmzCduGonCSC6+HKIMztPRQJs7n5PgZ7ieu+A5+ToCDfwTaVJrc0yAEQIvE2+5/1SNDMAe+ADn4cFDBhzt4KnBM3hSbcCo77MxxPJKJfnpaZtcwKWfBIW6FVOmeKagmc4= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (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 4TktR90nlbz3jBc; Tue, 27 Feb 2024 23:07:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4TktR86gvJz4NWS; Tue, 27 Feb 2024 23:07:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709075220; 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=5OpwuwZdv/1VfUmHnpmLmx5k1D0VVp1iokHLG12oa+Q=; b=AyAIuK2RJ/toVs3MmNOw8OZ2hSARXiiZdA2n59nxuF9//NYqS27RVW0b2YGIX95mpC3KVA x0DGaC8C+THIZnXQ2zYjjzhr+YcxggKXl0i2p1S3oKml80kP6Kt0V73kUcMlNCVdVP0fbl gWAI/OdEfIqiOI+GoB9rmpq6Had2FrZnfdIGarFEJWOViumgkT1J12X2UHSI7TOjXn2s1+ vPRAqqWirRx0r5LmB9cSqsQiIhVR9oUNXNy1UsW+fanSCTiZK9A6UW0salbTeVAqhIIJZj g2c7AFOf0JJDsRCs+sTmQTmP7WXsXgWp/FlhLbWnILH5o3JnkFqiCUTDEB5ACA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1709075220; a=rsa-sha256; cv=none; b=txqMZHv457EiMcsdSFx6SGnx2ksP/Ai4B2keHYvcUGjR/v5+Kj6bmbGq9N+t8CJDYqI7T7 QRTKjnW80CghzJCNVSQKH3lWap30IPaOpD0q3A0gnYQp97TH8MJB0zwEHKlqaY3yqlNr0X RQCC6LuiY3tcJ2Fme0dnPCcSk5Qv/1QRrnlIn/PHA0ocEFXnn+GuQa5cuCBP8bxhgRVhyb csrVCnP4fhZGQrsc1kqKgizzPgc+HUzZZN6ZbyzU75+DjyGDAddoEPjh44+hUir1DySnRB 3yyQ9Vnykzdx/RQ7RyWTd8WsD9raNiVRbGdVW256mjgi6hk3Cd/gIFEInP5I+w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709075220; 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=5OpwuwZdv/1VfUmHnpmLmx5k1D0VVp1iokHLG12oa+Q=; b=xPtCrSXB7OwZBBgAO3OhQNVbLAhV1GIG7UXDGyzRt/fsxsOdRrsv6/p7JP33MoiQoEC5X3 5MGDHkyHnXfl8DeIvU2leHyyhUpv1Wz9VthW8Ep8gN16k7QPrhPlEUDxZR70niPoh9rTDU Qylr7dMB9+iNzZR8c6Ce360jemj8hcv2/RAHicwYgB5qoNl1NK2WMLizxDZYoYVwvIkGsj OrNVxASI3xUIuNItlJYa6FonPNlP8dWtEePrTGzZfiubo/dh6xONZJCzL2YxhHZhL8G1Ig AkYZezlV0CsFUvYSTyJzaf9nCjdtiYu9Y60VA57twAMTIgfkTa36hAgSL8FtaQ== Received: from [128.232.109.25] (user-109-25.vpn.cl.cam.ac.uk [128.232.109.25]) (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 4TktR80gXkzcK5; Tue, 27 Feb 2024 23:06:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <704078b1-cb70-4b13-a721-0fed502db160@FreeBSD.org> Date: Tue, 27 Feb 2024 15:06:56 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: LoongArch: Change LOONGARCH_LINUX_NUM_GREGSET to 35 Content-Language: en-US To: Hui Li , gdb-patches@sourceware.org References: <20240221021401.32143-1-lihui@loongson.cn> <63303d10-d546-44a8-b7e5-5c469f9776ec@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.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,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2/26/24 5:25 PM, Hui Li wrote: > Hi, > > On 2024/2/23 上午8:33, John Baldwin wrote: >> On 2/20/24 6:14 PM, Hui Li wrote: >>> There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())" >>> in find_register_by_number() when gdb connects to gdbserver, this is >>> because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains 10 >>> reserved regs) is different with the number of regs (35) in the feature >>> file gdb/features/loongarch/base64.xml. Change >>> LOONGARCH_LINUX_NUM_GREGSET >>> to 35 to keep consistent with the xml file. >>> >>> without this patch: >>> >>> Execute on the target machine: >>> >>>    $ gdbserver 192.168.1.123:5678 ./test >>> >>> Execute on host machine: >>> >>>    $ gdb ./test >>>    (gdb) target remote 192.168.1.123:5678 >>> >>> Output on the target machine: >>> >>>    Process ./test created; pid = 67683 >>>    Listening on port 5678 >>>    Remote debugging from host 192.168.1.136, port 6789 >>>    gdbserver/regcache.cc:205: A problem internal to GDBserver has been >>> detected. >>>    find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' >>> failed. >>> >>> Output on host machine: >>> >>>    Remote debugging using 192.168.1.123:5678 >>>    Remote connection closed >>> >>> Signed-off-by: Hui Li >>> --- >>>   gdb/arch/loongarch.h | 2 +- >>>   1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/gdb/arch/loongarch.h b/gdb/arch/loongarch.h >>> index 4b7ab054ea0..6e51e1d097b 100644 >>> --- a/gdb/arch/loongarch.h >>> +++ b/gdb/arch/loongarch.h >>> @@ -33,7 +33,7 @@ enum loongarch_regnum >>>     LOONGARCH_ORIG_A0_REGNUM = 32,    /* Syscall's original arg0.  */ >>>     LOONGARCH_PC_REGNUM = 33,        /* Program Counter.  */ >>>     LOONGARCH_BADV_REGNUM = 34,        /* Bad Vaddr for Addressing >>> Exception.  */ >>> -  LOONGARCH_LINUX_NUM_GREGSET = 45,    /* 32 GPR, ORIG_A0, PC, BADV, >>> RESERVED 10.  */ >>> +  LOONGARCH_LINUX_NUM_GREGSET = 35,    /* 32 GPR, ORIG_A0, PC, BADV.  */ >>>     LOONGARCH_ARG_REGNUM = 8,            /* r4-r11: general-purpose >>> argument registers. >>>                         f0-f7: floating-point argument registers.  */ >>>     LOONGARCH_FIRST_FP_REGNUM = LOONGARCH_LINUX_NUM_GREGSET, >> >> Does anything depend on the gap being present here for FIRST_FP_REGNUM? >> That is, >> should you perhaps be moving the +10 down to LOONGARCH_FIRST_FP_REGNUM >> to keep the >> first FP register number the same? >> > > Thanks for your review. > > The purpose of this modification is to make LOONGARCH_FIRST_FP_REGNUM > equal to 35. In gdb and gdbserver code, tdesc reg number is defined > according to the feature file gdb/features/loongarch/*.xml(GPR: 0 ~ 34, > and FPR starts at 35). But first FPR reg number in regcache is > LOONGARCH_FIRST_FP_REGNUM(45), the total number of registers will not be > consistent with tdesc reg numbers. > > With this patch, LOONGARCH_FIRST_FP_REGNUM is changed to 35, > the 10 reserved registers are not included in total number of registers, > then all the reg numbers in regcache are consistent with tdesc reg numbers. > > I send v2 version with modified code and commit message to make this > change clearer. Ok. Mostly I was curious if there were existing stubs/servers that do not use the XML descriptions and assume that the first FP register is at register 45. That said, GDB should also be able to handle a different numbering from the remote target that doesn't match the regcache numbers and instead translates remote register numbers to regcache register numbers. -- John Baldwin