From patchwork Mon Mar 13 21:46:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 66325 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 87F213854830 for ; Mon, 13 Mar 2023 21:46:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 87F213854830 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678744012; bh=fZ+CCGdgdLArViJ9QBZnUkgerUNhHyBC9QecLlHvLK0=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=MxC695ngiqfCE68M/xRc01E6IuOH+XjJwwdPNy7DG0OlbhpzZfvC6/066dpbFImAf 4+wLNmPB9m1pDEWWFF3BegDOYV3afM99XBHDekyIvjHSiuf4kypRopjmXf4oMU0Rlw O4QpZo1EFEUWZK0RNwRapFpMsy+0byh9oynMlxUU= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E83B83858C30 for ; Mon, 13 Mar 2023 21:46:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E83B83858C30 Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-46-J_Bav0PFPJ6qv77oqskImQ-1; Mon, 13 Mar 2023 17:46:27 -0400 X-MC-Unique: J_Bav0PFPJ6qv77oqskImQ-1 Received: by mail-ed1-f71.google.com with SMTP id b1-20020aa7dc01000000b004ad062fee5eso18587615edu.17 for ; Mon, 13 Mar 2023 14:46:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678743985; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fZ+CCGdgdLArViJ9QBZnUkgerUNhHyBC9QecLlHvLK0=; b=P/2QBW9kJrHXVHbl5gXwDBs4+K3vZ+H7tUFbniGPz5M7FXKURzeNU8CcsTDnNx9MNv 9976t/cnFGwZ+YJTvC2ZBc3OYtSloNDY3+iDujQCoIqLKcTZ2TVTQHyF97zzCbohwQjf ZVev6UuOmJZsNcCsNJsAYE6kmyrR74GlTtr3E10fEp64qfjfkdxqU74DVzylbu2unu3g d3SaUxKNQ0oRu4Wbm28N1aDOA/FPAcxJHBcBhNrownXEgMLlHBip+v1BGbTNWinzZKv4 A8tYr7cQsngD2J+fDodLbPVtknDF7eby6RMJV3Qa55IqGy8My95U10qpNXPRkV8SPQHt x+Fw== X-Gm-Message-State: AO0yUKUNj0+Jh/+ozYuIlx1oEAYhrx5yfM0sm0xaqCxfLyuD5ali+qGh tzh6vZOVo75cAwp3aD2DL2eTp/FcEF/ikpnLtqYESnYkuZ6F4qMykdn1hIdUEQOIHMqDtccxPvf b2/lNcspN3ALmvVf4v/smGzjuXXgLG0iqEW6kwpNOq+BtfdP1zUWp1K3NKK3Pm9+xxBhTWTUD37 dvbNprIg== X-Received: by 2002:a17:907:9894:b0:92b:f119:3964 with SMTP id ja20-20020a170907989400b0092bf1193964mr13440ejc.37.1678743985670; Mon, 13 Mar 2023 14:46:25 -0700 (PDT) X-Google-Smtp-Source: AK7set+lJBhGhNHMZ8ihGzS7SA85zEJjd01UKKgoqhx6OxXZ8FZ1RKIYEa04q1QUuRu1JFXd7vx1wA== X-Received: by 2002:a17:907:9894:b0:92b:f119:3964 with SMTP id ja20-20020a170907989400b0092bf1193964mr13429ejc.37.1678743985360; Mon, 13 Mar 2023 14:46:25 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id xa13-20020a170907b9cd00b0091ec885e016sm273836ejc.54.2023.03.13.14.46.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 14:46:25 -0700 (PDT) To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 2/3] gdb/riscv: support c.ldsp and c.lwsp in prologue scanner Date: Mon, 13 Mar 2023 21:46:18 +0000 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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-Patchwork-Original-From: Andrew Burgess via Gdb-patches From: Andrew Burgess Reply-To: Andrew Burgess Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" Add support to the RISC-V prologue scanner for c.ldsp and c.lwsp instructions. This fixes some of the failures in gdb.base/unwind-on-each-insn.exp, though there are further failures that are not fixed by this commit. This change started as a wider fix that would address all the failures in gdb.base/unwind-on-each-insn.exp, however, that wider fix needed support for the two additional compressed instructions. When I added support for those two compressed instructions I noticed that some of the failures in gdb.base/unwind-on-each-insn.exp resolved themselves! Here's what's going on: The reason for the failures is that GDB is trying to build the frame-id during the last few instructions of the function. These are the instructions that restore the frame and stack pointers just prior to the return instruction itself. By the time we reach the function epilogue the stack offset that we calculated during the prologue scan is no longer valid, and so we calculate the wrong frame-id. However, in the particular case of interest here, the test function 'foo', the function is so simple and short that GDB's prologue scan could, in theory, scan every instruction of the function. I say "could, in theory," because currently GDB stops the prologue scan early when it hits an unknown instruction. The unknown instruction happens to be one of the compressed instructions that I'm adding support for in this commit. Now that GDB understands the compressed instructions the prologue scan really does go from the start of the function right up to the current program counter. As such, GDB sees that the stack frame has been allocated, and then deallocated, and so builds the correct frame-id. Of course, most real functions are not as simple as the test function 'foo'. As such, we can realistically rely on scanning right up to the end of the function. There are some instructions we always need to stop at because we can't reason about how they change the inferior state (e.g. a function call). The test function 'bar' is just such an example. After this commit, we can now build the frame-id correctly for every instruction in 'foo', but there are some tests still failing in 'bar'. --- gdb/riscv-tdep.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index ba7eab41ac6..5ef76555918 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -1668,11 +1668,20 @@ class riscv_insn m_imm.s = EXTRACT_ITYPE_IMM (ival); } - /* Helper for DECODE, decode 16-bit compressed I-type instruction. */ - void decode_ci_type_insn (enum opcode opcode, ULONGEST ival) + /* Helper for DECODE, decode 16-bit compressed I-type instruction. Some + of the CI instruction have a hard-coded rs1 register, while others + just use rd for both the source and destination. RS1_REGNUM, if + passed, is the value to place in rs1, otherwise rd is duplicated into + rs1. */ + void decode_ci_type_insn (enum opcode opcode, ULONGEST ival, + gdb::optional rs1_regnum = {}) { m_opcode = opcode; - m_rd = m_rs1 = decode_register_index (ival, OP_SH_CRS1S); + m_rd = decode_register_index (ival, OP_SH_CRS1S); + if (rs1_regnum.has_value ()) + m_rs1 = *rs1_regnum; + else + m_rs1 = m_rd; m_imm.s = EXTRACT_CITYPE_IMM (ival); } @@ -1959,6 +1968,10 @@ riscv_insn::decode (struct gdbarch *gdbarch, CORE_ADDR pc) decode_cl_type_insn (LD, ival); else if (is_c_lw_insn (ival)) decode_cl_type_insn (LW, ival); + else if (is_c_ldsp_insn (ival)) + decode_ci_type_insn (LD, ival, RISCV_SP_REGNUM); + else if (is_c_lwsp_insn (ival)) + decode_ci_type_insn (LW, ival, RISCV_SP_REGNUM); else /* None of the other fields of INSN are valid in this case. */ m_opcode = OTHER;