[Qemu-devel] [RFC] TCG unit testing

[Qemu-devel] [RFC] TCG unit testing

[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.

--------------------------------------------
# Test basic arithmetic, esp with constant arguments
CODE
0:	movi_i32	a0, 0x12345678
	movi_i32	a1, 0x87654321
	movi_tl		pc, 1
	exit_tb		0

1:	add_i32		a2, a1, a0
	sub_i32		a1, a1, a0
	movi_i32	t0, 1
	add_i32		a3, a0, t0
	sub_i32		a4, a0, t0
	movi_i32	t0, -1
	add_i32		a5, a0, t0
	sub_i32		a6, a0, t0
	movi_i32	t0, -0x5678
	add_i32		a7, a0, t0
	sub_i32		a8, a0, t0
	movi_i32	t0, 0x123456
	add_i32		a9, a0, t0
	sub_i32		a10, a0, t0
	movi_i32	t0, 0x12341234
	add_i32		a11, a0, t0
	sub_i32		a12, a0, t0
	call		done

RESULT
	a0	0x12345678
	a1	0x7530eca9
	a2	0x99999999
	a3	0x12345679
	a4	0x12345677
	a5	0x12345677
	a6	0x12345679
	a7	0x12340000
	a8	0x1234acf0
	a9	0x12468ace
	a10	0x12222222
	a11	0x246868ac
	a12	0x4444
-------------------------------------------

(2) The ram layout should be flexible enough to test specific scenarios

-------------------------------------------
# For 64-bit guest, 32-bit host, make sure we compare high-part of tlb
MEM
	ram	0x0_0000_0000, 4096
	ram	0x1_0000_0000, 4096

CODE
0:	movi_i64	b0, 0x12345678abcdef
	movi_i64	t1, 0
	movi_i64	t2, 0x1_0000_0000
	qemu_st32	b0, t1
	qemu_ld32	b1, t1
	qemu_ld32	b2, t2
	call		done

RESULT
	b0	0x12345678abcdef
	b1	0x12345678abcdef
	b2	0
-------------------------------------------

(3a) If we let "ioram" be defined via memory_region_init_io, with the "/l" and
"/b" qualifiers controlling the .endianness field of the region, then we can
test the memory access path all the way through.
(3b) The final test in the result section would *not* use the device interface
from memory.h, but rather examine the backing ram directly.

-------------------------------------------
MEM
        ioram/l 0, 4096                         # little-endian device
	ioram/b 4096, 4096			# big-endian device
CODE
0:      movi_tl         t0, 0x12345678
        movi_tl         t1, 0
        qemu_st32       t0, t1
	qemu_ld32	a0, t1
	movi_tl		t1, 4096
	qemu_st32	t0, t1
	qemu_ld32	a1, t1
        call            done
RESULT
	a0	0x12345678
	a1	0x12345678
        mem/b   0, 0x78, 0x56, 0x34, 0x12       # little-endian bytes
	mem/b	4096, 0x12, 0x34, 0x56, 0x78	# big-endian bytes
-------------------------------------------

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~

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

[Stefan Weil]

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
                  <------------------------->

Regards,
Stefan

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

[Richard Henderson]

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~

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

[Peter Maydell]

On 23 August 2013 22:18, Richard Henderson <rth@twiddle.net> wrote:
> 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.

Oh, TCI does that? That's just broken -- you can't treat all helpers the same
that way. You either need to have a bit of per-CPU glue code which knows
how to adjust things to the calling convention (which would defeat the point
of TCI being CPU-independent) or you need to defer to a library that can do
it (libffi would be the obvious choice) or you need to actually have the C
code in the interpreter make the call with all the correct argument types
(should be technically possible for qemu I guess since we have a fixed
set of helper functions and we know the types at compile time, though
it might be kind of painful).

-- PMM

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

[Stefan Weil]

Am 23.08.2013 23:18, schrieb Richard Henderson:
>
> 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.

TCI is special because it is the only TCG backend which works (more or less)
for all hosts, so it can be improved to be a reference implementation.

Then it will be possible to compare execution traces from TCI with other
TCG backends.

> 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~

Yes, those possible alignment issues were already discussed earlier.
Up to now, nobody cared enough to fix them. I have run some very
limited tests on ARM hardware. My tests did not trigger those problems.

I don't think that fixing the argument passing to helper functions is
very difficult: we have a limited set of different helper function
prototypes and can generate different calls for each case. This
might even speed up TCI a little bit because only necessary parameters
would be passed instead of the maximum number like it is done today.

This and other known (or unknown) problems of the TCI backend will of
course be fixed as soon as there are TCG unit tests which detect
these problems. :-) That's why I am very interested in such unit tests
and other tests for TCG backends.

Stefan

[Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing)

[Stefan Weil]

Am 23.08.2013 23:18, schrieb Richard Henderson:
> 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~

For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
configure.
Cross compilations cannot set that macro automatically (or is there some
way to
do this?), so a configure option is needed if the cross target is unknown.

Should we use this mechanism for all hosts (and move the definitions in
tcg-target.h
to a conditional definition in tcg.h), or should we use it only for TCI?

TCI on ARM works for most architectures when I set
TCG_TARGET_CALL_ALIGN_ARGS.
It only fails for qemu-alpha. The alpha disassembler does not work on 32
bit hosts,
therefore debugging is difficult.

Regards,
Stefan

Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args

[Richard Henderson]

On 09/10/2013 02:34 PM, Stefan Weil wrote:
> For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
> configure.  Cross compilations cannot set that macro automatically
> (or is there some way to do this?)

I can't think of a way that would be reasonable from configure.

> Should we use this mechanism for all hosts (and move the definitions in
> tcg-target.h to a conditional definition in tcg.h), or should we use it only for TCI?

I'd prefer a common solution, but it's something easy to get wrong
if there are multiple ABIs in play, e.g. PPC32.

Perhaps let's start with just TCI.

> The alpha disassembler does not work on 32 bit hosts,
> therefore debugging is difficult.

It works on i386.  What's your "not working" test case?


r~

Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args

[Stefan Weil]

Am 10.09.2013 23:52, schrieb Richard Henderson:
> On 09/10/2013 02:34 PM, Stefan Weil wrote:
>> For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
>> configure.  Cross compilations cannot set that macro automatically
>> (or is there some way to do this?)
> I can't think of a way that would be reasonable from configure.
>
>> Should we use this mechanism for all hosts (and move the definitions in
>> tcg-target.h to a conditional definition in tcg.h), or should we use it only for TCI?
> I'd prefer a common solution, but it's something easy to get wrong
> if there are multiple ABIs in play, e.g. PPC32.
>
> Perhaps let's start with just TCI.
>
>> The alpha disassembler does not work on 32 bit hosts,
>> therefore debugging is difficult.
> It works on i386.  What's your "not working" test case?
>
>
> r~

busybox-static from Debian running on 32 bit Linux:

$ alpha-linux-user/qemu-alpha -d in_asm
/usr/gnemul/qemu-alpha/bin/busybox pwd
host mmap_min_addr=0x10000
Reserved 0x21e000 bytes of guest address space
Relocating guest address space from 0x0000000020000000 to 0x20000000
guest_base  0x0
start    end      size     prot
0000000020000000-0000000020218000 0000000000218000 rwx
0000000040000000-0000000040002000 0000000000002000 ---
0000000040002000-0000000040802000 0000000000800000 rw-
0000000020216000-000000012021e000 0000000100008000 rwx
start_brk   0x0000000000000000
end_code    0x00000001202179bd
start_code  0x0000000120000000
start_data  0x0000000120000000
end_data    0x00000001202179bd
start_stack 0x0000000040801160
brk         0x000000012021dcb0
entry       0x00000001200d3fe0
IN:
0x00000001200d3fe0:  stq_c    zero,23096(t12)
0x00000001200d3fe4:  stq_c    zero,23096(t12)
0x00000001200d3fe8:  stq_c    zero,23096(t12)
0x00000001200d3fec:  stq_c    zero,23096(t12)
0x00000001200d3ff0:  stq_c    zero,23096(t12)
0x00000001200d3ff4:  stq_c    zero,23096(t12)
0x00000001200d3ff8:  stq_c    zero,23096(t12)
0x00000001200d3ffc:  stq_c    zero,23096(t12)

Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args

[Peter Maydell]

On 10 September 2013 23:04, Stefan Weil <sw@weilnetz.de> wrote:
> busybox-static from Debian running on 32 bit Linux:
>
> $ alpha-linux-user/qemu-alpha -d in_asm
> /usr/gnemul/qemu-alpha/bin/busybox pwd
> host mmap_min_addr=0x10000
> Reserved 0x21e000 bytes of guest address space
> Relocating guest address space from 0x0000000020000000 to 0x20000000
> guest_base  0x0

> start_code  0x0000000120000000

...that doesn't seem like it would fit in a 32 bit host
address space. Am I misinterpreting the log?

Try a 64 bit host and see if it's better?

-- PMM

Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args

[Stefan Weil]

Am 11.09.2013 00:22, schrieb Peter Maydell:
> On 10 September 2013 23:04, Stefan Weil <sw@weilnetz.de> wrote:
>> busybox-static from Debian running on 32 bit Linux:
>>
>> $ alpha-linux-user/qemu-alpha -d in_asm
>> /usr/gnemul/qemu-alpha/bin/busybox pwd
>> host mmap_min_addr=0x10000
>> Reserved 0x21e000 bytes of guest address space
>> Relocating guest address space from 0x0000000020000000 to 0x20000000
>> guest_base  0x0
>> start_code  0x0000000120000000
> ...that doesn't seem like it would fit in a 32 bit host
> address space. Am I misinterpreting the log?
>
> Try a 64 bit host and see if it's better?
>
> -- PMM

Hi,

it's the alpha start address. QEMU masks it to 32 bit for 32 bit targets.

On 64 bit hosts both disassembler and emulation (with and without TCI) work.

Stefan

Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing)

[Peter Maydell]

On 10 September 2013 22:34, Stefan Weil <sw@weilnetz.de> wrote:
> For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
> configure.
> Cross compilations cannot set that macro automatically (or is there some
> way to
> do this?), so a configure option is needed if the cross target is unknown.

I think setting TCG_TARGET_CALL_ALIGN_ARGS will
work only by fluke and in some cases. For TCI you need
to either:
 * really call each C function by its proper prototype
   (probably with something funky to pull this out of our
   existing macro definitions of helpers)
 * use libffi or some equivalent to get the calling convention
   right for you

-- PMM

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

[Lei Li]

On 08/24/2013 04:42 AM, 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
>                    <------------------------->

Really nice if we could support this!

>
> Regards,
> Stefan
>
>


-- 
Lei

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

[Aurelien Jarno]

On Fri, Aug 23, 2013 at 12:47:43PM -0700, Richard Henderson wrote:
> 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.

Given the regular breakages we have with TCG, it's really a gread idea.
Usually most of the targets are working correctly so the problem is not
found immediately.

> 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.

I think we should use as much as possible of the current infrastructure,
having two different main loops means they are going to be
desynchronised at some point.

Ideally it would be nice to have a machine called TCG (maybe with a few
variants for big/little endian, 32 and 64-bits) which loads TCG "code"
from a text file and execute it. Then we can imagine zillions of small
testcases like the GCC ones, and more can be added when a problem is
discovered and fixed.

> 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.
> 
> --------------------------------------------
> # Test basic arithmetic, esp with constant arguments
> CODE
> 0:	movi_i32	a0, 0x12345678
> 	movi_i32	a1, 0x87654321
> 	movi_tl		pc, 1
> 	exit_tb		0
> 
> 1:	add_i32		a2, a1, a0
> 	sub_i32		a1, a1, a0
> 	movi_i32	t0, 1
> 	add_i32		a3, a0, t0
> 	sub_i32		a4, a0, t0
> 	movi_i32	t0, -1
> 	add_i32		a5, a0, t0
> 	sub_i32		a6, a0, t0
> 	movi_i32	t0, -0x5678
> 	add_i32		a7, a0, t0
> 	sub_i32		a8, a0, t0
> 	movi_i32	t0, 0x123456
> 	add_i32		a9, a0, t0
> 	sub_i32		a10, a0, t0
> 	movi_i32	t0, 0x12341234
> 	add_i32		a11, a0, t0
> 	sub_i32		a12, a0, t0
> 	call		done
> 
> RESULT
> 	a0	0x12345678
> 	a1	0x7530eca9
> 	a2	0x99999999
> 	a3	0x12345679
> 	a4	0x12345677
> 	a5	0x12345677
> 	a6	0x12345679
> 	a7	0x12340000
> 	a8	0x1234acf0
> 	a9	0x12468ace
> 	a10	0x12222222
> 	a11	0x246868ac
> 	a12	0x4444
> -------------------------------------------
> 
> (2) The ram layout should be flexible enough to test specific scenarios
> 
> -------------------------------------------
> # For 64-bit guest, 32-bit host, make sure we compare high-part of tlb
> MEM
> 	ram	0x0_0000_0000, 4096
> 	ram	0x1_0000_0000, 4096

Maybe we can provide a few helper in the simple TCG machine to create
and remove TLB entries, or to memset the memory. That way each code that
is run can use a different memory mapping.

> CODE
> 0:	movi_i64	b0, 0x12345678abcdef
> 	movi_i64	t1, 0
> 	movi_i64	t2, 0x1_0000_0000
> 	qemu_st32	b0, t1
> 	qemu_ld32	b1, t1
> 	qemu_ld32	b2, t2
> 	call		done
> 
> RESULT
> 	b0	0x12345678abcdef
> 	b1	0x12345678abcdef
> 	b2	0
> -------------------------------------------
> 
> (3a) If we let "ioram" be defined via memory_region_init_io, with the "/l" and
> "/b" qualifiers controlling the .endianness field of the region, then we can
> test the memory access path all the way through.
> (3b) The final test in the result section would *not* use the device interface
> from memory.h, but rather examine the backing ram directly.
> 
> -------------------------------------------
> MEM
>         ioram/l 0, 4096                         # little-endian device
> 	ioram/b 4096, 4096			# big-endian device
> CODE
> 0:      movi_tl         t0, 0x12345678
>         movi_tl         t1, 0
>         qemu_st32       t0, t1
> 	qemu_ld32	a0, t1
> 	movi_tl		t1, 4096
> 	qemu_st32	t0, t1
> 	qemu_ld32	a1, t1
>         call            done
> RESULT
> 	a0	0x12345678
> 	a1	0x12345678
>         mem/b   0, 0x78, 0x56, 0x34, 0x12       # little-endian bytes
> 	mem/b	4096, 0x12, 0x34, 0x56, 0x78	# big-endian bytes
> -------------------------------------------
> 
> Thoughts?  Anything that we ought to be testing that I haven't thought of here,
> and that this sort of structure couldn't support?

As said above this kind of structure might be difficult to maintain
while we increase it with a lot more tests.

I think the call to helpers, with variable number of arguments and
types, should be tested. Probably also access to the host memory through
the non-qemu ld/st functions. And maybe the condition ops, especially
with some corner cases with signed/unsigned comparisons.

The problem I also see is the testing of optional ops.

Also what about user mode? At least the memory access is different.

> 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.

That would be really great if it can be implemented at some point.
Thanks for working on that.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

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

[Rob Landley]

On 09/02/2013 11:07:03 AM, Aurelien Jarno wrote:
> On Fri, Aug 23, 2013 at 12:47:43PM -0700, Richard Henderson wrote:
> > 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.
> 
> Given the regular breakages we have with TCG, it's really a gread  
> idea.
> Usually most of the targets are working correctly so the problem is  
> not
> found immediately.
> 
> > 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.
> 
> I think we should use as much as possible of the current  
> infrastructure,
> having two different main loops means they are going to be
> desynchronised at some point.
> 
> Ideally it would be nice to have a machine called TCG (maybe with a  
> few
> variants for big/little endian, 32 and 64-bits) which loads TCG "code"
> from a text file and execute it. Then we can imagine zillions of small
> testcases like the GCC ones, and more can be added when a problem is
> discovered and fixed.

Someday, I'd still like to hook Fabrice's old tinycc front end to tcg  
as the code generation backend...

Rob