So far I only have testcases for instruction and data address.
Not implemented is the mechanism that lets the debugger prevent a user
program from using triggers at all. I'll be adding that soonish.
The critical path is unchanged, but my experimenting shows the
simulation is slowed down about 8% by this code. Reducing the size of
trigger_match() (which is never called during my benchmark) fixes that,
but making it not be inlined has no effect. I suspect the slowdown comes
from cache alignment or something similar, and on a different CPU or
after more code changes the speed will come back.
Users can use this register to inspect and change the privilege level of
the core. It doesn't make any assumptions about the actual underlying
debug mechanism (as opposed to having the user change DCSR directly,
which may not exist in all debug implementations).
csrw instructions instantly return if the PC isn't serialized. Take note
of this, and don't enter debug mode until the instruction we just
executed actually completed.
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.
Tim Newsome
Andrew Waterman
Andrew Waterman
Colin Schmidt
Jonathan Neuschäfer