This means I don't know what hart to look at, so I might as well
invalidate the register cache. Without this, you might get stale
registers the first time you ask for them.
I thought OpenOCD did this, but it looks like that doesn't happen when
runningi in RTOS mode. With this I can get to the end of most of the
RTOS tests, but they SIGINT instead of exiting.
I'm not sure why this is necessary, but for some reason GDB is asking
for registers before OpenOCD thinks there's been a halt. This is really
just a workaround, but I need to refactor the v0.11 stuff anyway so I
don't want to figure it out.
This is a major rewrite of the RISC-V v0.13 OpenOCD port. This
shouldn't have any meaningful effect on the v0.11 support, but it does
add generic versions of many functions that will allow me to later
refactor the v0.11 support so it's easier to maintain both ports. This
started as an emergency feature branch and went on for a long time, so
it's all been squashed down into one commit so there isn't a big set of
broken commits lying around. The changes are:
* You can pass "-rtos riscv" to the target in OpenOCD's configuration
file, which enables multi-hart mode. This uses OpenOCD's RTOS
support to control all the harts from the debug module using commands
like "info threads" in GDB. This support is still expermental.
* There is support for RV64I, but due to OpenOCD limitations we only
support 32-bit physical addresses. I hope to remedy this by rebasing
onto the latest OpenOCD release, which I've heard should fix this.
* This matches the latest draft version of the RISC-V debug spec, as of
April 26th. This version fixes a number of spec bugs and should be
close to the final debug spec.
read_memory was doing autoexec-initialized commands, but wasn't using
ac_busy_delay to add delay or wait between the commands. This isn't the optimal
solution, but the whole read_memory sequence needs to be made more efficient
anyway, so this was the quick and dirty solution.
Palmer Dabbelt
Megan Wachs