Re: [PATCH] gdb/riscv: Add target description support

[Jim Wilson <jimw@sifive.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