From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C2TtK-0002K1-SQ for qemu-devel@nongnu.org; Wed, 01 Sep 2004 08:07:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C2TtI-0002IM-5i for qemu-devel@nongnu.org; Wed, 01 Sep 2004 08:07:05 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C2TtH-0002IF-VR for qemu-devel@nongnu.org; Wed, 01 Sep 2004 08:07:04 -0400 Received: from [151.189.21.47] (helo=mail-in-01.arcor-online.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1C2ToD-0005Je-PW for qemu-devel@nongnu.org; Wed, 01 Sep 2004 08:01:50 -0400 Date: Wed, 1 Sep 2004 13:17:40 +0200 From: Richard Zidlicky Subject: Re: [Qemu-devel] QEMU on SPARC host - Summary and suggested vl.c PATCH Message-ID: <20040901111740.GA2112@linux-m68k.org> References: <41353AAF.3050201@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <41353AAF.3050201@gmx.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bochnig@pool.math.tu-berlin.de, qemu-devel@nongnu.org On Wed, Sep 01, 2004 at 04:57:51AM +0200, Bochnig, Martin wrote: > (now in its own thread) > > Hi, > > Now we SPARC-host users are on the horns of a dilemma: QEMU's existing > SPARC support is optimized for SPARCv7 only. > While we are required to build for v9 / SPARC64, the build process gives > tons of errors caused by invalid type definitions/invalid size castings > and doesn't complete. > The whole sources may need to be adjusted (by a real hacker, not me). > I edited Makefile.target, Makefile and configure and tested several > '-mcpu=' and '-m32' vs. '-m64' settings - including '-mcpu=ultrasparc > -m32' which is to produce so called sparcv8plus ELF 32 binaries. > I tried to build statically. > I enabled bigendian and gprof in 'configure'. > The build did NEVER complete with '-mcpu=ultrasparc' - no matter how all > the other variations looked like. > So I could never test or even tune my theoretical %tick code (BTW: The > vl.o object builds fine). > op.o seemed to be broken and dyngen complained and was unable to > generate op.h. :-(( > > ../dyngen -o op.h op.o > dyngen: ret; restore; not found at end of op_setbe_T0_subl so look at the code generated for op_setbe_T0_subl in op.o, eg objdump -S op.o. Chances are that you have forgotten some no-reorder-block or noomit-fp compiler flags. Or the instructions have been reordered in some new way by the compiler or some V9 specific opcode. Just figure out what the compiler does instead of "ret; restore" and strip off these instructions. Richard