[PATCH 0/2] [PATCHv2] gdb/riscv: Improved register alias name creation

[Andrew Burgess]

Tom,

Thanks for the logs, these set me in the right direction to find the
mistake in my patch.

I now have two patches.  The first alone should be enough to get
things working for you now; it's basically the same patch as before
but with a small bug fix.

The second patch is a user experience improvement that seemed obvious
once I understood what was going wrong with the first patch.

After the first patch you should expect to be able to connect to the
remote and see this:

  (gdb) p $dscratch
  Could not fetch register "dscratch"; remote failure reply 'E14'
  (gdb) p $dscratch0
  Could not fetch register "dscratch"; remote failure reply 'E14'

However if you do 'info registers csr' you'll find this line:

  dscratch0       Could not fetch register "dscratch"; remote failure reply 'E14'

Which is a little odd as your target description clearly says you have
'dscratch', not 'dscratch0'.  After the second patch the same info
registers will now report:

  dscratch       Could not fetch register "dscratch"; remote failure reply 'E14'

This leaves just one question from me.  I thought that your original
thread started by saying that once upon a time you could successfully
read the dscratch and/or the dscratch0 registers.  The some patches
landed and you could no longer read the registers.

>From what I'm seeing though, the _actual_ failure to read the register
is all QEMU.  So my question, did I missunderstand the original
problem?  Is there a build of GDB where you are able to read actual
values from these registers?

Either way, I think these patches should go in, so let me know if they
help at all.

Thanks,
Andrew

---

Andrew Burgess (2):
  gdb/riscv: Improved register alias name creation
  gdb/riscv: Take CSR names from target description

 gdb/ChangeLog    |  25 +++++++
 gdb/riscv-tdep.c | 170 +++++++++++++++++++++++++++++++----------------
 2 files changed, 137 insertions(+), 58 deletions(-)

-- 
2.25.4