]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb/riscv: remove csr aliases created with DECLARE_CSR_ALIAS
authorAndrew Burgess <andrew.burgess@embecosm.com>
Thu, 26 Nov 2020 11:42:03 +0000 (11:42 +0000)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Wed, 2 Dec 2020 17:47:39 +0000 (17:47 +0000)
commit533b2ae07d0437d0f9ae26f2067c1eab7999c5ba
tree73fdeb12afd0ff7975a9a1aa0dccb0b41b2c26fd
parente45020422076c1014579ae8763fd253990ddf58e
gdb/riscv: remove csr aliases created with DECLARE_CSR_ALIAS

In this commit:

  commit 767a879e31ce31179e6135c2f991f670a35709fa
  Date:   Tue Jun 9 17:38:30 2020 +0100

      gdb/riscv: Improved register alias name creation

RISC-V GDB was changed to make use of the DECLARE_CSR_ALIAS macro to
define register aliases for some CSRs.  Actually, only one alias was
created 'dscratch' as an alias for 'dscratch0'.  All of the other
DECLARE_CSR_ALIAS lines (from include/opcode/riscv-opc.h) were
filtered out.

In this commit:

  commit 08ccfccf0ed825be9be2972594d4be4a2207ef13
  Date:   Mon Jun 8 10:54:53 2020 +0800

      RISC-V: Support debug and float CSR as the unprivileged ones.

Changes were made to include/opcode/riscv-opc.h so that GDB no longer
created even the dscratch alias.

This caused a test failure in gdb.arch/riscv-tdesc-regs.exp.

In looking at how to address this failure I think that the best
strategy is, for now at least, to just remove the code that tries to
create aliases with DECLARE_CSR_ALIAS.

My thoughts are that:

  1. At least some of the aliases are for CSRs where the register now
  has a completely different use.  Being able to reference the CSR
  using a completely inappropriate name just seems confusing.  This
  was solved by the filtering added in the first commit referenced
  above.  But we certainly don't want to blindly add all aliases.

  2. Names presented in a target description are always honoured, so
  if a user has a legacy target then they should just start sending a
  target description with their legacy register names in, this problem
  is then solved.

  3. It's easy enough to figure out which CSRs a target has with the
  info registers command, so missing an alias shouldn't be a big
  issue.

  4.  Allowing users to use names for registers that differ from the
  names the target announces doesn't feel like a critical feature.  If
  in the future targets want multiple names for a register then maybe
  we could/should extend target descriptions to allow the target to
  send aliases as well as the primary name.... but that can wait for
  another day.

So in this commit I remove the use of DECLARE_CSR_ALIAS, and remove
the test that was failing.

gdb/ChangeLog:

* riscv-tdep.c (riscv_create_csr_aliases): Remove use of
DECLARE_CSR_ALIAS.

gdb/testsuite/ChangeLog:

* gdb.arch/riscv-tdesc-regs.exp: Remove unwanted test.
gdb/ChangeLog
gdb/riscv-tdep.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.arch/riscv-tdesc-regs.exp