* Don't corrupt s0 when abstract CSR write fails.
* Support abstract FPR access then mstatus.FS=0
Discussion on the spec list leans towards this being a requirement.
Certainly users want their debugger to be able to access all registers
regardless of target state.
* Implement hasel/hawindow support.
This should allow simultaneous resume and halt to work.
* Fix anyrunning/anyhalted bits.
* Add --without-hasel argument for testing.
* Make halt/resume times more equal.
Switching threads after every instruction executed in debug mode leads
to a lot of extra instructions being executed on the "other" thread when
both are really supposed to halt/resume near-simultaneously. Fixed that
by adding wfi to debug_rom.S, and implementing it to switch to the other
hart as well as check for JTAG input.
When resuming, write the hart ID to the debug ROM so that the DM knows
which hart actually resumed. (Before simultaneous resume it just assumed
the current one.)
Also got rid of resume symbol in debug_rom.S since it had no purpose.
* Preserve Debug ROM entry points.
* Make sure minstret is correct when wfi happens.
1. Debug ROM wasn't actually writing 0xffffffff to the last word in
Debug RAM after an exception happened.
2. Fix a race where debug interrupts were cleared before that write
would have happened, so a debugger (gdbserver.cc in this case) might get
the wrong idea about whether an exception happened or not.
Why wasn't this wreaking havoc before?
As a result Debug ROM would always take the spontaneous halt code path.
This didn't hurt spike since (so far?) the spike debug handler doesn't
attempt to do anything quick while code is running. But now the ROM is
more correct.
This should replace the ROM hack I implemented earlier, but for now both
exist together.
Back to the point where gdb connects, core jumps to ROM->RAM->ROM.
I'm not thrilled about including a static copy in so many cc files, and
making the compiler throw it out. But without really grokking the
Makefile this is the best it's going to be.
Connect with gdb, and the core will jump to Debug ROM and start
executing it. Then it crashes when it jumps to 0x400 because Debug RAM
isn't implemented (and doesn't live there anyway, for now).
Tim Newsome
Megan Wachs
Andrew Waterman