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: Jim Wilson <jimw at sifive dot com>
- To: Andrew Burgess <andrew dot burgess at embecosm dot com>
- Cc: gdb-patches at sourceware dot org, Palmer Dabbelt <palmer at sifive dot com>, John Baldwin <jhb at freebsd dot org>
- Date: Sun, 18 Nov 2018 19:51:23 -0800
- Subject: Re: [PATCH] gdb/riscv: Add target description support
- References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com>
On Wed, Nov 14, 2018 at 6:58 AM Andrew Burgess
<andrew.burgess@embecosm.com> wrote:
> I'm proposing to merge this version if everyone is happy with it.
Looks like a few minor typos in the new docs, but otherwise it looks
good to me. I tested this riscv-linux native on a HiFive Unleashed
board, and with riscv-tests/debug using openocd and spike.
> +The @samp{org.gnu.gdb.riscv.fpu} feature is optional. If present it
> +should contains registers @samp{f0} through @samp{f31}, @samp{fflags},
> +@samp{frm}, and @samp{fcsr}. As with the cpu feature either the
> +architectural register names, or the ABI names can be used.
"should contains registers" -> "should contain registers"
> +The @samp{org.gnu.gdb.riscv.virtual} feature is optional. If present
> +it should contain registers that are not backed by real registers on
> +the target but are instead virtual, where the register value is
> +derived from other target state. In many ways these are like GDBs
> +pseudo-registers, except implemented by the target. Currently the
> +only register expected in this set is the one byte @samp{priv}
> +register that contains the targets privilege level in the least
> +significant two bits.
"targets privilege level" -> "target's privilege level"
> +The @samp{org.gnu.gdb.riscv.csr} feature is optional. If present it
> +should contain all of the targets standard CSRs. Standard CSRs are
> +those defined in the RISC-V specification documents. There is some
> +overlap between this feature and the fpu feature; the @samp{fflags},
> +@samp{frm}, and @samp{fcsr} registers could be in either feature. The
> +expectation is that these registers will be in the fpu feature if the
> +target has floating point hardware, but can be moved into the csr
> +feature if the target has the floating point control registers, but no
> +other floating point hardware.
"targets standard CSRs" -> "target's standard CSRs"
Jim