From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VI8QI-0007hw-Px for qemu-devel@nongnu.org; Fri, 06 Sep 2013 22:39:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VI8QB-0001hj-Eu for qemu-devel@nongnu.org; Fri, 06 Sep 2013 22:38:54 -0400 Received: from mail-ob0-f175.google.com ([209.85.214.175]:50005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VI8QB-0001hd-AU for qemu-devel@nongnu.org; Fri, 06 Sep 2013 22:38:47 -0400 Received: by mail-ob0-f175.google.com with SMTP id xn12so4163966obc.20 for ; Fri, 06 Sep 2013 19:38:45 -0700 (PDT) Date: Fri, 06 Sep 2013 21:38:43 -0500 From: Rob Landley References: <5217BC5F.4060306@twiddle.net> <20130902160703.GA10518@ohm.aurel32.net> In-Reply-To: <20130902160703.GA10518@ohm.aurel32.net> (from aurelien@aurel32.net on Mon Sep 2 11:07:03 2013) Message-Id: <1378521523.1985.16@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] TCG unit testing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel , Richard Henderson 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 =20 > backends, and > > maybe how to do regression testing on them. Having to begin the =20 > test from a > > guest binary, especially considering the vast cross-compilation =20 > problem, is > > pretty much a non-starter. >=20 > Given the regular breakages we have with TCG, it's really a gread =20 > idea. > Usually most of the targets are working correctly so the problem is =20 > not > found immediately. >=20 > > I've been thinking of a truly stripped down target for the purpose, =20 > with a > > special-purpose machine loop and main to go with it. I.e. avoid =20 > vl.c. >=20 > I think we should use as much as possible of the current =20 > infrastructure, > having two different main loops means they are going to be > desynchronised at some point. >=20 > Ideally it would be nice to have a machine called TCG (maybe with a =20 > 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 =20 as the code generation backend... Rob=