Debug Tests =========== Debugging requires many system components to all work together. The tests here perform an end-to-end test, communicating with gdb and OpenOCD. If a simulator or hardware passes all these tests, then you can be pretty confident that the actual debug interface is functioning correctly. Requirements ============ The following should be in the user's path: * riscv64-unknown-elf-gcc * riscv64-unknown-elf-gdb (can be overridden with `--gdb` when running gdbserver.py manually) * spike (can be overridden with `--sim_cmd` when running gdbserver.py manually) * openocd (can be overridden with `--server_cmd` when running gdbserver.py manually) Usage ===== To run a quick smoke test against spike, run `make`. For a more comprehensive test against a variety of spike configurations, run `make all`. To run tests against hardware, or a specific spike configuration, manually invoke gdbserver.py: `./gdbserver.py targets/.py` You can run just a single test by specifying any part of its name on the command line, eg: `./gdbserver.py targets/RISC-V/spike64.py S0` runs SimpleS0Test. Once that test has failed, you can look at the log file to get an idea of what might have gone wrong. For custom targets, you can create a .py file anywhere and pass its path on the command line. The Targets class in `targets.py` contains documentation on what every variable means. Log Files ========= All output from tests ends up in the `logs/` subdirectory, with one log file per test. If a test fails, this is where to look. Debug Tips ========== You can see what spike is doing by adding `-l` to the spike command, eg.: `./gdbserver.py --sim_cmd "$RISCV/bin/spike -l" targets/RISC-V/spike32.py Breakpoint` You can see what OpenOCD is doing by adding `-d` to the OpenOCD command, eg.: `./gdbserver.py --server_cmd "openocd -d" targets/RISC-V/spike32.py Breakpoint` You can run gdb under valgrind by passing --gdb, eg.: `./gdbserver.py --gdb "valgrind riscv64-unknown-elf-gdb" targets/RISC-V/spike64.py DownloadTest`