From patchwork Sat Feb 23 20:39:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 31571 Received: (qmail 103501 invoked by alias); 23 Feb 2019 20:40:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 103483 invoked by uid 89); 23 Feb 2019 20:40:07 -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=baggage, doctype, !doctype, DOCTYPE X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Feb 2019 20:40:05 +0000 Received: by mail-wm1-f65.google.com with SMTP id t15so4776948wmi.5 for ; Sat, 23 Feb 2019 12:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TXhRAM5fqaFKmCXimeBFACNCQq9rb1U1cdxhhZGllyo=; b=eU/gdhOfL7FJMphy3CBEx6p2OazisqJLCL+DDLr9Q6a92ekdHofvN9CXkfFgUsPyOh ihXT5L+YEulV0cxDy5DlWSGMGeP7xnO2wGlEnrM0UQfEiBCNRFviHS7IzWeb/ppcUamu /ls/rLdfs6qybkwIziDS/3yzJ8GSMR2wR7ua7gP1HDfo/ElQFCA4VtvlGKQyJFzmGw/P ClNEBTWQYhOk5DdgCjvKwltdcB90xiCq4iXrU4j+I3X/cbFvZzFibMFWfcTMU28yjoeh rnOjkNbwm564ZNQx6SLYkuKzZIq63R5daAFlR8VEcZouLtC67kzD79Nh/+co72f5gSzm qTyA== Return-Path: Received: from localhost ([199.203.143.44]) by smtp.gmail.com with ESMTPSA id k203sm1567108wmf.44.2019.02.23.12.40.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 23 Feb 2019 12:40:01 -0800 (PST) Date: Sat, 23 Feb 2019 22:39:58 +0200 From: Andrew Burgess To: Tom Tromey Cc: gdb-patches@sourceware.org, jimw@sifive.com, palmer@sifive.com, jhb@FreeBSD.org Subject: Re: [PATCH] gdb/riscv: Add target description support Message-ID: <20190223203958.GA15942@embecosm.com> References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com> <87r2bz67ol.fsf@tromey.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87r2bz67ol.fsf@tromey.com> X-Fortune: If you keep anything long enough, you can throw it away. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes * Tom Tromey [2019-02-22 10:42:50 -0700]: > >>>>> "Andrew" == Andrew Burgess writes: > > Andrew> This is a slightly revised version of the RISC-V target descriptions > Andrew> patch. > > I'm seeing a difference that I think was introduced by this patch and I > am wondering whether it is intentional and whether something ought to be > done about it. I'm really not sure, this is my first foray into RISC-V > and into target descriptions. > > With an older gdb (8.2), with remote debugging enabled: > > (gdb) p $fflags > Sending packet: $p42#d6...Ack > Packet received: 0000000000000000 > $1 = 0 > > Here you can see that gdb thinks the register number for fflags is 0x42. > And, that is the value of RISCV_CSR_FFLAGS_REGNUM, even in today's gdb > master: > > (top-gdb) p/x RISCV_CSR_FFLAGS_REGNUM > $1 = 0x42 > > However with a newer gdb, with an older qemu, I get a failure: > > Sending packet: $p41#d5...Ack > Packet received: E14 > Could not fetch register "fflags"; remote failure reply 'E14' > > Here you can see gdb is sending 0x41. > > RISCV_CSR_FFLAGS_REGNUM is computed by: > > RISCV_LAST_FP_REGNUM = 64, /* Last Floating Point Register */ > RISCV_FIRST_CSR_REGNUM = 65, /* First CSR */ > [...] > #define DECLARE_CSR(name, num) \ > RISCV_ ## num ## _REGNUM = RISCV_FIRST_CSR_REGNUM + num, > > Then from riscv-opc.h: > > #define CSR_FFLAGS 0x1 > [...] > DECLARE_CSR(fflags, CSR_FFLAGS) > > So, in effect it is RISCV_LAST_FP_REGNUM + 2. > > > But then, e.g., in the 32-bit FPU description: > > Andrew> +static int > Andrew> +create_feature_riscv_32bit_fpu (struct target_desc *result, long regnum) > Andrew> +{ > [...] > Andrew> + tdesc_create_reg (feature, "ft11", regnum++, 1, NULL, 32, "ieee_single"); > Andrew> + tdesc_create_reg (feature, "fflags", regnum++, 1, NULL, 32, "int"); > > I think this is where the discrepancy lies. > > > I'm not really sure what ought to be done here. Do you have any ideas? So you are correct. When I added the target description support I failed to consider backward compatibility with existing tools enough. So, when GDB connect to a target that doesn't provide a target description a default description is used. This default has features created by calls to the functions like create_feature_riscv_32bit_fpu and friends, and it is these functions that are picking the default register numbering. In an ideal world, with no legacy baggage, these create_feature_* functions shouldn't really care about register numbering, which is how I have them setup right now. However, it doesn't have to be that way, we can force the numbering in the create_feature_* functions. The patch below tries to restore the legacy numbering for fcsr, frm, and fflags. Does this restore the behaviour you are expecting? One other thing to note about the change to target descriptions was that the default target descriptions don't include any CSRs. At the time I figured that guessing about what CSRs a target supports wasn't a good thing to do, and instead we should be encouraging targets to move to proper target description support in order to support CSRs. The consequence is that when you connect to your legacy QEMU the only CSRs you'll have access too are the fcsr, frm, and fflags (as these get grouped in with FP registers as they should be available if the FP registers are available). One possibility as an alternative to this patch is writing a target description file that describes you legacy QEMU and loading this into GDB with 'set tdesc filename FILENAME', with this approach you could force the register numbering to match your expectations, and you'd get access to your CSRs back. Let me know if you think the patch below is an improvement, though it's possibly not as pure (with hard-coded register numbering) than before, I'd be happy to have this merged if the compatibility was important. Thanks, Andrew --- [PATCH] gdb/riscv: Use legacy register numbers in default target description When the target description support was added to RISC-V, the register numbers assigned to the fflags, frm, and fcsr control registers in the default target descriptions didn't match the register numbers used by GDB before the target description support was added. What this means is that if a tools exists in the wild that is using hard-coded register number, setup to match GDB's old behaviour, then this will have been broken (for fflags, frm, and fcsr) by the move to target descriptions. QEMU is such a tool. There are a couple of solutions that could be used to work around this issue: - The user can create their own xml description file with the register numbers setup to match their old tool, then load this by telling GDB 'set tdesc filename FILENAME'. - Update their old tool to use the newer default numbering scheme, or better yet add proper target description support to their tool. - We could have RISC-V GDB change to maintain the old defaults. This patch implements the last of these ideas, changing the default numbering to match the old behaviour. This change is only visible to targets that don't supply their own xml description file and instead rely on GDB's default numbering. gdb/ChangeLog: * features/riscv/32bit-cpu.xml: Add register numbers. * features/riscv/32bit-fpu.c: Regenerate. * features/riscv/32bit-fpu.xml: Add register numbers. * features/riscv/64bit-cpu.xml: Add register numbers. * features/riscv/64bit-fpu.c: Regenerate. * features/riscv/64bit-fpu.xml: Add register numbers. --- gdb/ChangeLog | 9 +++++++++ gdb/features/riscv/32bit-cpu.xml | 6 +++++- gdb/features/riscv/32bit-fpu.c | 2 ++ gdb/features/riscv/32bit-fpu.xml | 12 ++++++++---- gdb/features/riscv/64bit-cpu.xml | 6 +++++- gdb/features/riscv/64bit-fpu.c | 2 ++ gdb/features/riscv/64bit-fpu.xml | 12 ++++++++---- 7 files changed, 39 insertions(+), 10 deletions(-) diff --git a/gdb/features/riscv/32bit-cpu.xml b/gdb/features/riscv/32bit-cpu.xml index 466f2c0648..0d07aaec85 100644 --- a/gdb/features/riscv/32bit-cpu.xml +++ b/gdb/features/riscv/32bit-cpu.xml @@ -5,9 +5,13 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> + + - + diff --git a/gdb/features/riscv/32bit-fpu.c b/gdb/features/riscv/32bit-fpu.c index 22e80d640e..a19780aab0 100644 --- a/gdb/features/riscv/32bit-fpu.c +++ b/gdb/features/riscv/32bit-fpu.c @@ -9,6 +9,7 @@ create_feature_riscv_32bit_fpu (struct target_desc *result, long regnum) struct tdesc_feature *feature; feature = tdesc_create_feature (result, "org.gnu.gdb.riscv.fpu"); + regnum = 33; tdesc_create_reg (feature, "ft0", regnum++, 1, NULL, 32, "ieee_single"); tdesc_create_reg (feature, "ft1", regnum++, 1, NULL, 32, "ieee_single"); tdesc_create_reg (feature, "ft2", regnum++, 1, NULL, 32, "ieee_single"); @@ -41,6 +42,7 @@ create_feature_riscv_32bit_fpu (struct target_desc *result, long regnum) tdesc_create_reg (feature, "ft9", regnum++, 1, NULL, 32, "ieee_single"); tdesc_create_reg (feature, "ft10", regnum++, 1, NULL, 32, "ieee_single"); tdesc_create_reg (feature, "ft11", regnum++, 1, NULL, 32, "ieee_single"); + regnum = 66; tdesc_create_reg (feature, "fflags", regnum++, 1, NULL, 32, "int"); tdesc_create_reg (feature, "frm", regnum++, 1, NULL, 32, "int"); tdesc_create_reg (feature, "fcsr", regnum++, 1, NULL, 32, "int"); diff --git a/gdb/features/riscv/32bit-fpu.xml b/gdb/features/riscv/32bit-fpu.xml index 6a44b842b8..1eaae9119e 100644 --- a/gdb/features/riscv/32bit-fpu.xml +++ b/gdb/features/riscv/32bit-fpu.xml @@ -5,9 +5,13 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> + + - + @@ -40,7 +44,7 @@ - - - + + + diff --git a/gdb/features/riscv/64bit-cpu.xml b/gdb/features/riscv/64bit-cpu.xml index c4d83de09b..b8aa424ae4 100644 --- a/gdb/features/riscv/64bit-cpu.xml +++ b/gdb/features/riscv/64bit-cpu.xml @@ -5,9 +5,13 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> + + - + diff --git a/gdb/features/riscv/64bit-fpu.c b/gdb/features/riscv/64bit-fpu.c index 8cbd7484ab..b93cb4ec03 100644 --- a/gdb/features/riscv/64bit-fpu.c +++ b/gdb/features/riscv/64bit-fpu.c @@ -17,6 +17,7 @@ create_feature_riscv_64bit_fpu (struct target_desc *result, long regnum) field_type = tdesc_named_type (feature, "ieee_double"); tdesc_add_field (type_with_fields, "double", field_type); + regnum = 33; tdesc_create_reg (feature, "ft0", regnum++, 1, NULL, 64, "riscv_double"); tdesc_create_reg (feature, "ft1", regnum++, 1, NULL, 64, "riscv_double"); tdesc_create_reg (feature, "ft2", regnum++, 1, NULL, 64, "riscv_double"); @@ -49,6 +50,7 @@ create_feature_riscv_64bit_fpu (struct target_desc *result, long regnum) tdesc_create_reg (feature, "ft9", regnum++, 1, NULL, 64, "riscv_double"); tdesc_create_reg (feature, "ft10", regnum++, 1, NULL, 64, "riscv_double"); tdesc_create_reg (feature, "ft11", regnum++, 1, NULL, 64, "riscv_double"); + regnum = 66; tdesc_create_reg (feature, "fflags", regnum++, 1, NULL, 32, "int"); tdesc_create_reg (feature, "frm", regnum++, 1, NULL, 32, "int"); tdesc_create_reg (feature, "fcsr", regnum++, 1, NULL, 32, "int"); diff --git a/gdb/features/riscv/64bit-fpu.xml b/gdb/features/riscv/64bit-fpu.xml index fd14ebced8..794854cc01 100644 --- a/gdb/features/riscv/64bit-fpu.xml +++ b/gdb/features/riscv/64bit-fpu.xml @@ -5,6 +5,10 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> + + @@ -13,7 +17,7 @@ - + @@ -46,7 +50,7 @@ - - - + + +