From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3qK0-0000WN-1n for qemu-devel@nongnu.org; Tue, 12 May 2009 07:38:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3qJu-0000VX-Hx for qemu-devel@nongnu.org; Tue, 12 May 2009 07:38:54 -0400 Received: from [199.232.76.173] (port=44144 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3qJt-0000VL-Mb for qemu-devel@nongnu.org; Tue, 12 May 2009 07:38:50 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37310 helo=mx2.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M3qJt-0003Qf-6k for qemu-devel@nongnu.org; Tue, 12 May 2009 07:38:49 -0400 From: Ulrich Hecht Subject: Re: [Qemu-devel] [PATCH] TCG S/390 backend Date: Tue, 12 May 2009 13:38:45 +0200 References: <1241526283-22190-1-git-send-email-uli@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200905121338.45589.uli@suse.de> Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org On Tuesday 05 May 2009, malc wrote: > On Tue, 5 May 2009, Ulrich Hecht wrote: > > Now i386, AMD64, ARM, SH4, and m68k system emulators work. MIPS > > works at least as well as on an AMD64 host, i.e. the test image from > > qemu.org just > > Should work with '-M mips'. It complains about a missing "mips_bios.bin" then, which isn't in=20 pc-bios. > > sits there without doing anything. The SPARC test image fails with a > > memory access exception in the target system, but works on an AMD64 > > host, so there probably still is a bug somewhere in the backend. > > Tried to compare `-d in_asm' outputs of S390/AMD64 when using > deterministic execution (`-icount N')? I found the problem: TCG does not zero- or sign-extend arguments to=20 function calls. Unlike, for instance, AMD64, 32-bit arithmetic ops on=20 S/390 leave the upper 32 bits of the destination register untouched, so=20 there could be any kind of garbage there. If a helper taking a 64-bit=20 argument is called with the result of such an operation, stuff breaks.=20 IMO, TCG should do the extension in tcg_reg_alloc_call(), but that seems=20 to be impossible because it has no information on the types of the input=20 arguments the callee expects. Working around this in the backend is=20 hardly possible as it does not have the information either. I have the suspicion that even on other 64-bit hosts, this only works by=20 accident (if it does at all): Even if the 32-bit arithmetic op does sign=20 extension, what if the function argument is a pointer? Depending on the=20 address, the function may get a value with a lot of F's in front... Any ideas? CU Uli --=20 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)