From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LridY-000370-7r for qemu-devel@nongnu.org; Wed, 08 Apr 2009 21:01:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LridS-00036e-Pg for qemu-devel@nongnu.org; Wed, 08 Apr 2009 21:00:58 -0400 Received: from [199.232.76.173] (port=58956 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LridS-00036b-Jq for qemu-devel@nongnu.org; Wed, 08 Apr 2009 21:00:54 -0400 Received: from csl.cornell.edu ([128.84.224.10]:2612 helo=vlsi.csl.cornell.edu) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LridS-00078i-6Q for qemu-devel@nongnu.org; Wed, 08 Apr 2009 21:00:54 -0400 Received: from stanley.csl.cornell.edu (stanley.csl.cornell.edu [128.84.224.15]) by vlsi.csl.cornell.edu (8.13.4/8.13.4) with ESMTP id n3910hoK011097 for ; Wed, 8 Apr 2009 21:00:48 -0400 (EDT) Date: Wed, 8 Apr 2009 21:00:42 -0400 (EDT) From: Vince Weaver Subject: Re: [Qemu-devel] mipsIV support for mips-linux-user In-Reply-To: <20090408221724.GE26602@hall.aurel32.net> Message-ID: <20090408205500.A76201@stanley.csl.cornell.edu> References: <20090329165112.G16354@stanley.csl.cornell.edu> <20090330010551.GD12026@hall.aurel32.net> <20090329220159.E17939@stanley.csl.cornell.edu> <20090330043539.GE12026@hall.aurel32.net> <20090330131050.L20376@stanley.csl.cornell.edu> <20090408221724.GE26602@hall.aurel32.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 >> Because of this the generated assembly in the debug output >> unconditionally generates an illegal instruction exception the first time >> a cop1x instruction is executed (in my case, "msub.d") > > This instruction is clearly marked as MIPS64 only in the manual. I'm running MIPSIV compiled o32 binaries. Even though the binaries are 32-bits, they are running on a 64-bit enabled OS. (I have actual r12k and r5k machines running Debian Linux. They have 64-bit kernels but 32-bit userspace). mips-linux-user can run these executables fine if you hack it so that cop1x instructions are enabled. Perhaps the proper solution is to run the binaries under mips64-linux-user, but there you run into the 64-bit qemu-linux-user can't load 32-bit ELF files problem. I'm also not sure if mips64-linux-user implements the o32 syscalls. > I think this should be enabled in cpu_reset(), where env->hflags is > setup for user mode. That's currently what I am doing to enable these binaries to run. > But I am actually concern about the results you get when enabling > MIPS_HFLAG_COP1X. If your program is expecting to have the FPU in 64-bit > mode you may have really strange results. Did you check them? I'm running the Spec2k benchmarks and the results are as close as can be expected to the actual hardware. Vince