From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C2WHp-0000RY-Ks for qemu-devel@nongnu.org; Wed, 01 Sep 2004 10:40:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C2WHn-0000R7-RR for qemu-devel@nongnu.org; Wed, 01 Sep 2004 10:40:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C2WHn-0000R4-O2 for qemu-devel@nongnu.org; Wed, 01 Sep 2004 10:40:31 -0400 Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1C2WCr-0002Vj-AI for qemu-devel@nongnu.org; Wed, 01 Sep 2004 10:35:25 -0400 Message-ID: <4135DDA2.9040608@gmx.com> Date: Wed, 01 Sep 2004 16:33:06 +0200 From: "Bochnig, Martin" MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU on SPARC host - Summary and suggested vl.c PATCH References: <41353AAF.3050201@gmx.com> <20040901111740.GA2112@linux-m68k.org> In-Reply-To: <20040901111740.GA2112@linux-m68k.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: bochnig@pool.math.tu-berlin.de, 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 Hi, thank you for your valuable hints, thoughts, comments. I hope I will manage to get things running - earlier or later. Most of my systems are SPARC based (all except 1 PC). Furthermore I would love to see people using QEMU on top of SPARC hw (both on Solaris and LinUX as well as *BSD). I'll keep in touch with you / the ml. Thanx, Martin Richard Zidlicky wrote: > 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 > >