Fix missing setup in test_turbostep.

[riscv-tests.git] / debug / README.md

diff --git a/debug/README.md b/debug/README.md
index 2be795b870baa1f327d3251ac376d21aeaa5ece8..56f69db07ec6a1cf6c009a97d1d1314b6b860834 100644 (file)
--- a/debug/README.md
+++ b/debug/README.md
@@ -1,3 +1,47 @@
-Debugging requires many of a system components to all work together.  The goal
-is to collect some tests that test gdb with spike, and gdb talking to real
-hardware through openocd.
+Debug Tests
+===========
+
+Debugging requires many system components to all work together. The tests here
+perform an end-to-end test, communicating only with gdb. If a simulator or
+hardware passes all these tests, then you can be pretty confident that the
+actual debug interface is functioning correctly.
+
+Targets
+=======
+
+64-bit Spike
+------------
+
+`./gdbserver.py --spike64 --cmd $RISCV/bin/spike`
+
+32-bit Spike
+------------
+
+`./gdbserver.py --spike32 --cmd $RISCV/bin/spike`
+
+32-bit SiFive Core on Supported FPGA Boards &  Hardware
+-------------------------------------
+
+`./gdbserver.py --freedom-e300`
+
+32-bit rocket-chip core in Simulation
+-------------------------------------
+
+`./gdbserver.py --freedom-e300-sim`
+
+
+Debug Tips
+==========
+
+You can run just a single test by specifying <class>.<function> on the command
+line, eg: `./gdbserver.py --spike64 --cmd $RISCV/bin/spike
+SimpleRegisterTest.test_s0`.
+Once that test has failed, you can look at gdb.log and (in this case) spike.log
+to get an idea of what might have gone wrong.
+
+You can see what spike is doing by add `-l` to the spike command, eg.:
+`./gdbserver.py --spike32 --cmd "$RISCV/bin/spike -l"
+DebugTest.test_breakpoint`. (Then look at spike.log.)
+
+You can run gdb under valgrind by passing --gdb, eg.: `./gdbserver.py --spike64
+--gdb "valgrind riscv64-unknown-elf-gdb" -- -v DownloadTest`.