From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 2D7163858D34 for ; Fri, 1 Mar 2024 04:16:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D7163858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2D7163858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709266592; cv=none; b=Ll4pvpCJ+YTpJ+bYyhc80K/bSABJQOhLhJlCGDeYCqfjOa4y76VZ5geldhP0EhNql+TJjRgkxBQV3CP4a7s6EpCJUd08hKmSHRQ1NG7BdrJ4+3Cy6tr+q7t1enTAggrdT0TZBfuvb6SxbMCiDjSHmwMTLJz/hoKBtMV1aLkYVAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709266592; c=relaxed/simple; bh=/4OpzXVWL+P3Ze3yhss4DMiZgtmaoZcTo379T0I05c8=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=gl1S0T6SbfzKqHAp3hDX6EkWX6R7So2ZFMpByb+Gq/IazkJa/q17dyOOBQnDZKI16XwNNdjHGKtANBJNGrbMX+BM3YTS3V2W6B3hTlwU4oRfvNi1J85wAs4TpL/mlc6BwwHUbz9dTl6EqU7PjFb48IQVbQULZN91eyxtUnNDuuY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8AxeeiaVuFlaSwTAA--.29205S3; Fri, 01 Mar 2024 12:16:26 +0800 (CST) Received: from [10.130.0.191] (unknown [113.200.148.30]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxnhOXVuFll2xLAA--.14522S3; Fri, 01 Mar 2024 12:16:23 +0800 (CST) Subject: Re: [PATCH] gdb: LoongArch: Change LOONGARCH_LINUX_NUM_GREGSET to 35 To: John Baldwin , gdb-patches@sourceware.org References: <20240221021401.32143-1-lihui@loongson.cn> <63303d10-d546-44a8-b7e5-5c469f9776ec@FreeBSD.org> <704078b1-cb70-4b13-a721-0fed502db160@FreeBSD.org> From: Hui Li Message-ID: Date: Fri, 1 Mar 2024 12:16:23 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <704078b1-cb70-4b13-a721-0fed502db160@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:AQAAf8BxnhOXVuFll2xLAA--.14522S3 X-CM-SenderInfo: 5olk3xo6or00hjvr0hdfq/ X-Coremail-Antispam: 1Uk129KBj93XoWxCrWkXF4UXw1DWrWUtw4DKFX_yoWrAw45p3 9YkF1jkFWrKr1rJr1Ut3WUW34UtF1rt3WUZ345tF18Gr4q9ry2qr4qgr4q9F17Xw4kJr1j vr1UAa1xuF4UAabCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUv2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07 AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1wL 05UUUUU== X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00,BODY_8BITS,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_NUMSUBJECT,NICE_REPLY_A,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 2024/2/28 上午7:06, John Baldwin wrote: > 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. > Hi, Thanks for your reminder and suggestion. Now all existing stubs/servers(kgdb、gdbserver) does not contain 10 reserved registers, and the first FP register number is 35. Therefore, this is the best way to modify at present. Thanks, Hui