README: document record/replay support

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20170704144859.17644-5-alex.bennee@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

1 files changed, 20 insertions, 4 deletions

diff --git a/README b/README
index cabe6e6..312e9cd 100644
--- a/README
+++ b/README
@@ -107,6 +107,26 @@ mismatch status to its standard output.
 NB that in the register dump the r15 (pc) value will be given
 as an offset from the start of the binary, not an absolute value.
 
+While the master/slave setup works well it is a bit fiddly for running
+regression tests and other sorts of automation. For this reason risu
+supports recording a trace of its execution to a file. For example:
+
+  risu --master FxxV_across_lanes.risu.bin -t FxxV_across_lanes.risu.trace
+
+And then playback with:
+
+  risu FxxV_across_lanes.risu.bin -t FxxV_across_lanes.risu.trace
+
+Ideally it should be built with zlib to compress the trace files which
+would otherwise be huge. If building with zlib proves too tricky you
+can pipe to stdout and an external compression binary using "-t -".
+
+  risu --master FxxV_across_lanes.risu.bin -t - | gzip --best > trace.file
+
+and:
+
+  gunzip -c trace.file | risu -t - FxxV_across_lanes.risu.bin
+
 File format
 -----------
 
@@ -203,10 +223,6 @@ implementation, for example) but only ARM is tested.
  * we don't actually compare FP status flags, simply because
 I'm pretty sure qemu doesn't get them right yet and I'm more
 interested in fixing gross bugs first.
- * there isn't currently any support for a "record and replay
-results" mode. This would allow you to record the correct
-results from the ARM host once and then test a model implementation
-even if you didn't have the corresponding native hardware.
  * You can compile statically to avoid the requirement for the ARM
 chroot for qemu testing but you can no longer use gethostbyname() and need
 to specify your hosts by IP address.