]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb/riscv: add support for vector registers in target descriptions
authorAndrew Burgess <andrew.burgess@embecosm.com>
Tue, 4 May 2021 10:41:09 +0000 (11:41 +0100)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Mon, 21 Jun 2021 19:47:13 +0000 (20:47 +0100)
commit96f842cbdb37bb84fb1bab914304a3eff152ad0d
tree93009c3a8c2e392680af0424e86c05fa325d068a
parentd52b8007213eea4d1f33e3a604481f390d37b52a
gdb/riscv: add support for vector registers in target descriptions

This commit adds support to RISC-V GDB for vector registers in the
incoming target description.

The vector registers should be described in a feature called
"org.gnu.gdb.riscv.vector", and should contain the register v0 to
v31.  There's no restriction on the size or type of these registers,
so the target description can set these up as it requires.

However, if the target feature is present then all of the registers
must be present, and they must all be the same size, these
requirements are, I believe, inline with the RISC-V vector extension.

The DWARF register numbers for the vector registers have been added,
and the code to map between GDB's internal numbering and the DWARF
numbering has been updated.

I have not yet added a feature/riscv/*.xml file for the vector
extension, the consequence of this is that we can't, right now, detect
vector registers on a native target, this patch is all about
supporting vectors on a remote target.

It is worth noting that I don't actually have access to a RISC-V
target with vectors, so the only testing that this patch has had has
been done using 'set tdesc filename ....' to load a target description
to which I have manually added the vector feature.  This has shown
that the vector register feature can be successfully parsed, and that
the registers show up in the expected register groups.

Additionally, the RISC-V vector extension is currently at v0.10, which
is also the v1.0 draft release.  However, this extension is not yet
finalised.  It is possible (but unlikely I think) that the register
set could change between now and the final release of the vector
extension.  If this were to happen then we would potentially end up
changing the requirements for the new org.gnu.gdb.riscv.vector
feature.  I really don't think it is likely that the register set will
change this late in the process, and even if it did, changing the
feature requirements will not be a problem as far as I am
concerned (when the alternative is GDB just continues without this
feature for now).

gdb/ChangeLog:

* NEWS: Mention new target feature name.
* arch/riscv.c (riscv_create_target_description): GDB doesn't
currently create target descriptions containing vector registers.
* arch/riscv.h (struct riscv_gdbarch_features) <vlen>: New member
variable.
<operator==>: Also compare vlen.
<hash>: Also include vlen.
* riscv-tdep.c (riscv_feature_name_vector): New static global.
(struct riscv_vector_feature): New struct.
(riscv_vector_feature): New static global.
(riscv_register_reggroup_p): Ensure vector registers are part of
the 'all' group, and part of the 'vector' group.
(riscv_dwarf_reg_to_regnum): Handle vector registers.
(riscv_gdbarch_init): Check vector register feature.
* riscv-tdep.h: Add vector registers to GDB's internal register
numbers, and to the DWARF register numbers.

gdb/doc/ChangeLog:

* gdb.texinfo (RISC-V Features): Mention vector register feature.
gdb/ChangeLog
gdb/NEWS
gdb/arch/riscv.c
gdb/arch/riscv.h
gdb/doc/ChangeLog
gdb/doc/gdb.texinfo
gdb/riscv-tdep.c
gdb/riscv-tdep.h