From d27d66bc1bdbef0cbfe43d88597576e173317c01 Mon Sep 17 00:00:00 2001 From: Tim Newsome Date: Mon, 25 Jan 2021 11:27:23 -0800 Subject: [PATCH] Document how vector registers are exposed to gdb. See https://github.com/riscv/riscv-openocd/pull/570 Change-Id: Ie7cdef3717e107a9df0b48316cfbc547dea9a7fd Signed-off-by: Tim Newsome Reviewed-on: https://review.openocd.org/c/openocd/+/6776 Tested-by: jenkins Reviewed-by: Antonio Borneo --- doc/openocd.texi | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/doc/openocd.texi b/doc/openocd.texi index 61d3987383..8e50585389 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -10212,6 +10212,43 @@ A @emph{hart} is a hardware thread. A hart may share resources (eg. FPU) with another hart, or may be a separate core. RISC-V treats those the same, and OpenOCD exposes each hart as a separate core. +@subsection Vector Registers + +For harts that implement the vector extension, OpenOCD provides access to the +relevant CSRs, as well as the vector registers (v0-v31). The size of each +vector register is dependent on the value of vlenb. RISC-V allows each vector +register to be divided into selected-width elements, and this division can be +changed at run-time. Because OpenOCD cannot update register definitions at +run-time, it exposes each vector register to gdb as a union of fields of +vectors so that users can easily access individual bytes, shorts, words, +longs, and quads inside each vector register. It is left to gdb or +higher-level debuggers to present this data in a more intuitive format. + +In the XML register description, the vector registers (when vlenb=16) look as +follows: + +@example + + + + + + + + + + + + + + +... + + +@end example + @subsection RISC-V Debug Configuration Commands @deffn {Config Command} {riscv expose_csrs} n[-m|=name] [...] -- 2.30.2