This is a much more comprehensive test of OpenOCD behavior when harts
become unavailable.

To test OpenOCD behavior when one or more harts are powered down.

Also change the test itself to require less RAM than it did previously.
(It had required more than 32KB.)

It would fail intermittently. We can't guarantee all harts resume
simultaneously. When we let multiple harts run to a breakpoint at the
end of the same loop, one is likely to get there first, and the second
won't make it.

To avoid this problem, run for a short amount of time instead of to a
breakpoint.

Before it might fail incorrectly, because main was close to trap_entry.

* Specify trigger type=2 in trigger.S

Previous tests implicitly assume triggers only support type=2. However,
a trigger may support multiple types, i.e., type=15. This commit
explicitly specifies type=2 in trigger.S to support type 15.

* Update debug/programs/trigger.S

Co-authored-by: Tim Newsome <tim@sifive.com>
Signed-off-by: YenHaoChen <39526191+YenHaoChen@users.noreply.github.com>

Signed-off-by: YenHaoChen <39526191+YenHaoChen@users.noreply.github.com>
Co-authored-by: Tim Newsome <tim@sifive.com>

Between October 13 and October 19, something happened that makes the
multi-spike tests 4 times slower. Rolling back spike, OpenOCD, or
riscv-tests doesn't affect this. Presumably it's due to a kernel or
python change in my Ubuntu system.

I don't have time to look at this right now, so just increase the timeouts. :-(

If I had to guess, there could be a bug in rbb_daisychain.py that wastes
a lot of time.

https://github.com/riscv-software-src/riscv-isa-sim/pull/889 put a UART
at the address we were using in our 32-bit debug tests.

Fix long line to make pylint happy.

Get coverage of progbuf FPR accesses.

Using the new spike support merged in
https://github.com/riscv-software-src/riscv-isa-sim/pull/1109

debug: Add --debug_server arg to open gdb on OpenOCD

Not as useful as I'd like because we don't connect until after examine()
has completed, and the test is likely to time out while debugging. But
good to have, and maybe I'll expand on it one day.

update gdbserver.py; tolerance value of MemorySampleTest()

The control sequences (^[[?2004h and ^[[?2004l) occur after the
gdb.command, which results in Exception fault. This commit removes the
control sequences and strips out the blank lines (^M).

These can change at any time and that is OK.

I don't have time to fix the bug right now, and nobody has run into the
bug yet in any case.

Turn semihosting_fileio on for every hart. This test still fails if it
ends up running on hart 1 instead of 0, but at least it's closer to
passing. Feels like the remaining problem is in OpenOCD.