From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32875 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPeNT-0000f7-L8 for qemu-devel@nongnu.org; Mon, 06 Dec 2010 11:57:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPeNS-0005BR-K4 for qemu-devel@nongnu.org; Mon, 06 Dec 2010 11:57:27 -0500 Received: from mail.codesourcery.com ([38.113.113.100]:43019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPeNS-0005Aj-AI for qemu-devel@nongnu.org; Mon, 06 Dec 2010 11:57:26 -0500 Date: Mon, 6 Dec 2010 11:57:22 -0500 From: Nathan Froyd Subject: Re: [Qemu-devel] [PATCH 1/8] ARM: Fix decoding of VFP forms of VCVT between float and int/fixed Message-ID: <20101206165721.GF25904@nightcrawler> References: <1289499842-28818-1-git-send-email-peter.maydell@linaro.org> <1289499842-28818-2-git-send-email-peter.maydell@linaro.org> <20101206163043.GE25904@nightcrawler> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org 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