Re: [Qemu-devel] [RFC] TCG unit testing

[Richard Henderson <rth@twiddle.net>]

On 08/23/2013 01:42 PM, Stefan Weil wrote:
> 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

I don't see how TCI really comes into this except as Yet Another Backend to be
tested.  Indeed, such unit testing could show that TCI is in fact broken wrt
helpers, depending on the host abi.

E.g. tci never defines TCG_TARGET_CALL_ALIGN_ARGS.  Thus if one uses tci on an
ARM host, a helper like

DEF_HELPER_FLAGS_2(store_fpcr, TCG_CALL_NO_RWG, void, env, i64)

will have its arguments loaded into TCI's R0, R1, R2, and thence into the ARM
r0, r1, r2.  But the ARM abi requires the i64 input to be aligned, and thus it
should be r0, r2, r3.


r~