https://bugs.libre-soc.org/show_bug.cgi?id=985

diff --git a/openpower/test_api.mdwn b/openpower/test_api.mdwn
index 9a447c10c07ad542096ce4b618670da3fbf263f6..1403cac3c6679f3271514d205c77e9ffc300cfd5 100644 (file)
--- a/openpower/test_api.mdwn
+++ b/openpower/test_api.mdwn
@@ -99,4 +99,17 @@ itself. This was where bug
 came into play: to add the expected new Simulator (cavatools)
 in as another option to triage against.
 
+Cavatools already has the same gdb debug interface as QEMU,
+so it is expected to be reasonably straightforward to add.
+The qemu interaction utilises a python-based gdbremote client
+to first upload a binary into memory, followed by commands
+to set the contents of registers, including the Program Counter.
+A breakpoint is set, at the end of the program.
+Finally QEMU is permitted to run, and following the trigger of
+the breakpoint, memory contents and register contents are
+dumped (over the gdb-remote interfacce) and from that they
+can be compared against other implementations - or the Expected
+Results - or the Compliance Test Suite expected responses.
+Cavatools is expected to follow the exact same process, using
+the exact same python-based gdbremote client.