This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] gdb/riscv: Add target description support
- From: Tom Tromey <tom at tromey dot com>
- To: Andrew Burgess <andrew dot burgess at embecosm dot com>
- Cc: gdb-patches at sourceware dot org, jimw at sifive dot com, palmer at sifive dot com, jhb at FreeBSD dot org
- Date: Fri, 22 Feb 2019 10:42:50 -0700
- Subject: Re: [PATCH] gdb/riscv: Add target description support
- References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com>
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> 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?
thanks,
Tom