aboutsummaryrefslogtreecommitdiff
path: root/depcomp
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2021-05-04 11:41:09 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-06-21 20:47:13 +0100
commit96f842cbdb37bb84fb1bab914304a3eff152ad0d (patch)
tree93009c3a8c2e392680af0424e86c05fa325d068a /depcomp
parentd52b8007213eea4d1f33e3a604481f390d37b52a (diff)
downloadgdb-96f842cbdb37bb84fb1bab914304a3eff152ad0d.zip
gdb-96f842cbdb37bb84fb1bab914304a3eff152ad0d.tar.gz
gdb-96f842cbdb37bb84fb1bab914304a3eff152ad0d.tar.bz2
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.
Diffstat (limited to 'depcomp')
0 files changed, 0 insertions, 0 deletions