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

Andrew Burgess
2020-06-11T13:16:20Z

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