Use mstatus.MPP to check existence of U-mode
[riscv-tests.git] / debug / README.md
1 Debug Tests
2 ===========
3
4 Debugging requires many system components to all work together. The tests here
5 perform an end-to-end test, communicating with gdb and OpenOCD.
6 If a simulator or hardware passes all these tests, then you can be pretty
7 confident that the actual debug interface is functioning correctly.
8
9 Targets
10 =======
11
12 64-bit Spike
13 ------------
14
15 `./gdbserver.py targets/RISC-V/spike64.py`
16
17 32-bit Spike
18 ------------
19
20 `./gdbserver.py targets/RISC-V/spike32.py`
21
22 32-bit SiFive Core on Supported FPGA Boards & Hardware
23 ------------------------------------------------------
24
25 `./gdbserver.py targets/SiFive/E300.py`
26 `./gdbserver.py targets/SiFive/HiFive1.py`
27
28 Custom Target
29 -------------
30
31 For custom targets, you can create a .py file anywhere and pass its path on the
32 command line. The Targets class in `targets.py` contains documentation on what
33 every variable means.
34
35
36 Log Files
37 =========
38
39 All output from tests ends up in the `logs/` subdirectory, with one log file
40 per test. If a test fails, this is where to look.
41
42 Debug Tips
43 ==========
44
45 You can run just a single test by specifying any part of its name on the
46 command line, eg: `./gdbserver.py targets/RISC-V/spike64.py S0` runs
47 SimpleS0Test. Once that test has failed, you can look at the log file to get
48 an idea of what might have gone wrong.
49
50 You can see what spike is doing by adding `-l` to the spike command, eg.:
51 `./gdbserver.py --sim_cmd "$RISCV/bin/spike -l" targets/RISC-V/spike32.py Breakpoint`
52
53 You can see what OpenOCD is doing by adding `-d` to the OpenOCD command, eg.:
54 `./gdbserver.py --server_cmd "openocd -d" targets/RISC-V/spike32.py Breakpoint`
55
56 You can run gdb under valgrind by passing --gdb, eg.: `./gdbserver.py
57 --gdb "valgrind riscv64-unknown-elf-gdb" targets/RISC-V/spike64.py
58 DownloadTest`