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

[Tom Tromey <tom@tromey.com>]

>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:

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

[...]

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

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

We discussed this on irc a little.  The tests where I would connect and
print various registers don't seem to reflect the failures I was
actually seeing.  So, for example "print $dscratch" might say "= void"
... meaning this was an uninitialized convenience variable rather than a
register.

The actual failure is that some operation in gdb fails, saying a
register isn't available.  For example, one test case fails when it
tries to do an inferior call.

I applied your patches to git master (no local patches at all) and it
fails like so:

(gdb) call debug.trace (me, "You")
Could not fetch register "mucounteren"; remote failure reply 'E14'

However, if I check  out commit d8af906814b (the one before the first
round of RISC-V changes we're talking about), it works:

(gdb) call debug.trace (me, "You")
(gdb)

Tom