Am 23.08.2013 21:47, schrieb Richard Henderson:
I've been thinking for a while about how to reliably test TCG backends, and
maybe how to do regression testing on them. Having to begin the test from a
guest binary, especially considering the vast cross-compilation problem, is
pretty much a non-starter.
I've been thinking of a truly stripped down target for the purpose, with a
special-purpose machine loop and main to go with it. I.e. avoid vl.c.
My current idea is that the test file consists of 3 sections: guest memory
layout, raw TBs, and expected results. Perhaps best explained with some
examples:
(1a) I've split up this test into two TBs to prevent some constant folding.
(1b) The guest machine should have enough registers to make it easy to perform
lots of tests at once. Even better if we can avoid the complication of memory.
[...]
Thoughts? Anything that we ought to be testing that I haven't thought of here,
and that this sort of structure couldn't support?
It may be some time before I can progress this enough to usefulness, but I
wanted to get this written down while it is fresh in my head.
r~
Since the addition of the TCG interpreter backend, there exist two
backends for each supported host. It is possible to run user code
with well defined instruction order (no asynchronous events like
interrupts) with both backends and to compare the execution
flow. I did that while developing TCI. The process can be reversed:
TCI could be used as reference to test any other backend.
Another approach for testing TCG backends might work like this:
Modifying QEMU so that it is possible to feed the TCG backend
with single TCG opcodes would allow testing some part of the
processing chain:
target opcodes -> tcg opcodes -> host opcodes
<------------------------->