On Mon, Dec 06, 2010 at 04:48:25PM +0000, Peter Maydell wrote: > I'm not sure how well it would fit into being committed to qemu (yet): > it works as a program where you run half of it on real ARM hardware > and the other half under qemu (or valgrind) and it compares register > results after executing instructions by looking at the sigcontext struct > in a signal handler. Plus there's a perl script to generate random > instruction set sequences to feed the test program. It could be made > more automated and independent of having a reference bit of hardware > but I haven't got round to that yet. (Also since it has utility outside of > just testing qemu I'm not sure if it really belongs in the qemu repo.)
That does sound a little heavyweight. Scripting gdb is also a possibility. FWIW--and this is not particularly conducive to random insn sequences--the approach taken when doing the AltiVec bits was to have code that looked like: for each insn: for a suitable set of inputs: setup interesting registers (status control registers etc.) load inputs into registers execute record interesting post conditions in file.out You'd get an output file from real hardware and an output file from the simulator and then compare them, fixing differences as you go. The actual code included bits to compare the files as well as doing the generation. The output files can be somewhat large, but I'm sure clever engineering could be applied to make them smaller. Of course, the *real* problems are in undefined-behavior land. :) -Nathan