From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IrcsU-0004n7-74 for qemu-devel@nongnu.org; Mon, 12 Nov 2007 12:15:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IrcsS-0004ih-9q for qemu-devel@nongnu.org; Mon, 12 Nov 2007 12:15:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IrcsR-0004iJ-Tv for qemu-devel@nongnu.org; Mon, 12 Nov 2007 12:15:11 -0500 Received: from ns.suse.de ([195.135.220.2] helo=mx1.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 1IrcsO-0001nQ-R1 for qemu-devel@nongnu.org; Mon, 12 Nov 2007 12:15:11 -0500 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 25C3620831 for ; Mon, 12 Nov 2007 18:14:58 +0100 (CET) From: Ulrich Hecht Subject: Re: [Qemu-devel] s390 host support Date: Mon, 12 Nov 2007 18:14:43 +0100 References: <20071110204219.GA12456@wavehammer.waldi.eu.org> In-Reply-To: <20071110204219.GA12456@wavehammer.waldi.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200711121814.44245.uli@suse.de> Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Saturday 10 November 2007, Bastian Blank wrote: > Thimo Seufer asked me to check if the s390 host supports works at all. > It did not even build, dyngen failed. A 31-bit build of the CVS code works fine for me. (At least if I add the=20 br %rANY fix that is also in your patch and the jcc patch that Thiemo=20 has not committed yet.) A 31-bit build using your patch works as well, but it also needs the jcc=20 patch. The only reason it needs to be compiled with -march=3Dz900 is the=20 use of larl in the inline assembly code, which can be avoided by simply=20 omitting it in the PARAMx macros (the bras already writes the address to=20 the register) and reverting to the code currently in CVS for=20 GOTO_LABEL_PARAM. (The GOTO_TB hack does not seem to be necessary any=20 more.) > I digged into the problem and=20 > found the following: > gcc for s390 generates a data table after each function if necessary > instead of immediate loads. It actually generates it inline, doing something like op_something: bras %r13, 8 .long ... In other words, it branches over the data, storing the "return address"=20 (which is actually a pointer to the data) in r13. > (g5, the oldest supported processor only=20 > suports one halfword immediate load.) dyngen is not prepared for that > and fails. > I found that gcc moves this data into the .rodata section=20 > if generating code for z900 and above, which looked like a possible > way to support this. (My) GCC only does this when generating 64-bit code. > - Support R_390_PC32DBL relocation, including relocations into > sections. Again, my GCC only generates this relocation when compiling 64-bit code.=20 With your patch and some obvious fixes (ELFCLASS64, GETPC,=20 $hostlongbits)) it builds as 64-bit, but it segfaults in the first=20 translation block. CU Uli --=20 Heute ist - Dr. Sun Yat-sens Geburtstag (in Taiwan) - Gedenktag (in Bermuda, Cayman-Inseln) - Tag der Veteranen (in den USA (26 Staaten)) - Unabh=E4ngigkeit von Cartagena (in Kolumbien) SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)