Message ID | 20181103032033.21653-1-jimw@sifive.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 100425 invoked by alias); 3 Nov 2018 03:20:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 100392 invoked by uid 89); 3 Nov 2018 03:20:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=sk:riscv_l, RV64GC, rv64gc, Hx-spam-relays-external:209.85.215.195 X-HELO: mail-pg1-f195.google.com Received: from mail-pg1-f195.google.com (HELO mail-pg1-f195.google.com) (209.85.215.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 03 Nov 2018 03:20:38 +0000 Received: by mail-pg1-f195.google.com with SMTP id k1-v6so1778186pgq.1 for <gdb-patches@sourceware.org>; Fri, 02 Nov 2018 20:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=from:to:cc:subject:date:message-id; bh=H+ta4gb8h9voBPdJqYJCWxjScaxCV4wJ+54K9g+V7y8=; b=m89/Mi2bgrx3KgFFlEJENbbB/nSxIPmxM8SBd71f35C/Biw/nrwrE+BEe3XkBfBtvu JSzSHijlQYy2u7Sumzqv2i6LeoZ8TW/4ZdJM64ZaWdhnpmWGUd0QoGVlyuBbzBb0SrMB f9Bjlq30vFyARCgVx2ZokC8qYOSItLPM+zLIixpKGXs/EY0AlmstDLLRODgMRc9SgXDK 5ltAYlUQY2CBbVEFWdTgzfz/Z5LOHtIGCHh9XmRVmWmIRK45+01WUVS3mxEjJFdOfWnD ga+PzZw8RvzEqVLBgT8qtAohJ2PIVPIPSw7e0RfZSPZK7sTNg8Prn2NXJHsOhWteoUNy N+YA== Return-Path: <jimw@sifive.com> Received: from rohan.hsd1.ca.comcast.net ([2601:646:c100:8240:ea:3ff3:d04b:a7d0]) by smtp.gmail.com with ESMTPSA id m3-v6sm14460630pgj.52.2018.11.02.20.20.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 20:20:36 -0700 (PDT) From: Jim Wilson <jimw@sifive.com> To: gdb-patches@sourceware.org Cc: Jim Wilson <jimw@sifive.com> Subject: [PATCH] RISC-V: Fix xlen to flen typo in FP reg handling. Date: Fri, 2 Nov 2018 20:20:33 -0700 Message-Id: <20181103032033.21653-1-jimw@sifive.com> |
Commit Message
Jim Wilson
Nov. 3, 2018, 3:20 a.m. UTC
This fixes a bug in FP register handling for targets where xlen != flen. Tested against riscv-test/debug where it fixes a few failures. Also tested on RV64GC linux with the gdb testsuite where it has no effect. gdb/ * riscv-tdep.c (riscv_register_type): Use riscv_isa_flen for FP regs not riscv_isa_xlen. --- gdb/riscv-tdep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
* Jim Wilson <jimw@sifive.com> [2018-11-02 20:20:33 -0700]: > This fixes a bug in FP register handling for targets where xlen != flen. > Tested against riscv-test/debug where it fixes a few failures. Also tested > on RV64GC linux with the gdb testsuite where it has no effect. > > gdb/ > * riscv-tdep.c (riscv_register_type): Use riscv_isa_flen for FP regs > not riscv_isa_xlen. Can you hold off merging this patch please. There's a non-obvious reason why this uses xlen here (even though it's the wrong thing to do). The reason is something to do with remote targets, when the remote target reads a register then it initialises a cache that contains the types of all registers (for the sizes I think), for FP regs right now, that results in a call to read MISA. This read requires the remote to initialise a cache of all the register types, which results in a read of MISA. Which requires the remote to initialise a cache ..... So we get stuck in infinite recursion :-( I'm pretty sure the above is basically correct, but I'd have to do some additional tests to get an exact explanation for you. However, don't worry. I'm currently working on proper target description support. I had hoped to get it posted this week, but it now looks like it will be early next week. I just need final testing and a bit of cleanup / ChangeLogs writing etc. The target description patch removes the MISA reading stuff completely right now, and fixes this xreg instead of freg hack. So could I ask, please don't push this until say the end of next week. If I haven't posted the target description patch by then, then go ahead and I'll accept that my remote tests will break. Thanks, Andrew > --- > gdb/riscv-tdep.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c > index db372e2163..b94802aa97 100644 > --- a/gdb/riscv-tdep.c > +++ b/gdb/riscv-tdep.c > @@ -630,7 +630,7 @@ riscv_register_type (struct gdbarch *gdbarch, int regnum) > } > else if (regnum <= RISCV_LAST_FP_REGNUM) > { > - regsize = riscv_isa_xlen (gdbarch); > + regsize = riscv_isa_flen (gdbarch); > switch (regsize) > { > case 4: > -- > 2.17.1 >
On Sat, Nov 3, 2018 at 1:34 AM Andrew Burgess <andrew.burgess@embecosm.com> wrote: > However, don't worry. I'm currently working on proper target > description support. Do you perhaps mean XML register set support? I started working on a patch for that. This is needed for our OpenOCD and QEMU support. Meanwhile, I can hold off on this patch. Jim
diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index db372e2163..b94802aa97 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -630,7 +630,7 @@ riscv_register_type (struct gdbarch *gdbarch, int regnum) } else if (regnum <= RISCV_LAST_FP_REGNUM) { - regsize = riscv_isa_xlen (gdbarch); + regsize = riscv_isa_flen (gdbarch); switch (regsize) { case 4: