From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JoiUI-0006sw-EG for qemu-devel@nongnu.org; Wed, 23 Apr 2008 13:10:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JoiUH-0006sZ-QO for qemu-devel@nongnu.org; Wed, 23 Apr 2008 13:10:30 -0400 Received: from [199.232.76.173] (port=41105 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JoiUH-0006sV-LK for qemu-devel@nongnu.org; Wed, 23 Apr 2008 13:10:29 -0400 Received: from ik-out-1112.google.com ([66.249.90.183]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JoiUH-0002Qr-5b for qemu-devel@nongnu.org; Wed, 23 Apr 2008 13:10:29 -0400 Received: by ik-out-1112.google.com with SMTP id c29so663950ika.2 for ; Wed, 23 Apr 2008 10:10:28 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 20:09:58 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] Compilation broken in SVN version and a debug register question In-Reply-To: <527518.23522.qm@web57011.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <527518.23522.qm@web57011.mail.re3.yahoo.com> 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 4/23/08, Balazs Attila-Mihaly (Cd-MaN) wrote: > Hello all. > > I fail to compile the version 4242 from the SVN (which I checked out ~1 hour ago). On an Ubuntu 7.10 host with gcc-3.4 and ./configure --target-list=i386-softmmu, I get the following error: > > make -C i386-softmmu all > make[1]: Entering directory `/home/cdman/qemu/trunk/i386-softmmu' > gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -fno-reorder-blocks -fno-gcse -fno-optimize-sibling-calls -fno-crossjumping -fno-align-labels -fno-align-jumps -fno-align-functions -mpreferred-stack-boundary=2 -fomit-frame-pointer -m32 -I. -I.. -I/home/cdman/qemu/trunk/target-i386 -I/home/cdman/qemu/trunk -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/cdman/qemu/trunk/tcg -I/home/cdman/qemu/trunk/tcg/i386 -I/home/cdman/qemu/trunk/fpu -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/home/cdman/qemu/trunk/slirp -c -o op.o /home/cdman/qemu/trunk/target-i386/op.c > /home/cdman/qemu/trunk/target-i386/ops_sse.h: In function `op_pshufw_mmx': > /home/cdman/qemu/trunk/target-i386/ops_sse.h:597: error: unable to find a register to spill in class `GENERAL_REGS' > /home/cdman/qemu/trunk/target-i386/ops_sse.h:597: error: this is the insn: > (insn:HI 18 17 19 0 /home/cdman/qemu/trunk/target-i386/ops_sse.h:592 (set (strict_low_part (subreg:HI (reg/v:DI 58 [ r ]) 0)) > (mem/s/j:HI (plus:SI (mult:SI (reg:SI 62) > (const_int 2 [0x2])) > (reg/v/f:SI 60 [ s ])) [0 ._w S2 A16])) 54 {*movstricthi_1} (insn_list 16 (insn_list 12 (insn_list 50 (nil)))) > (expr_list:REG_DEAD (reg:SI 62) > (nil))) > /home/cdman/qemu/trunk/target-i386/ops_sse.h:597: confused by earlier errors, bailing out > make[1]: *** [op.o] Error 1 > make[1]: Leaving directory `/home/cdman/qemu/trunk/i386-softmmu' > make: *** [subdir-i386-softmmu] Error 2 > > Is this related to the recent discussion about MMX/SSE instructions? Yes. Maybe the patches here help: http://lists.gnu.org/archive/html/qemu-devel/2008-03/msg00320.html > Also, I have a weird behaviour with qemu-0.9.0 (I will test it against the SVN snapshot as soon as I can get it to compile :)). The behavior is related to hardware breakpoints. I use a Linux host and Windows XP guest and in the guest I use a user-mode debugger (Olly - http://ollydbg.de/) to debug a program. Software breakpoints work ok, but hardware breakpoints only work when I run __with__ kqemu (which is really weird, since the usual response for all the problems is "try it without kqemu" :)). Is this a known limitation or a bug? Should the code which sets the debug registers be augmented to flush the TB cache and the dyngen code changed to take into account the value of the debug registers (and raise an exception there)? But if this is the case, why does it work with kqemu enabled? No idea. You seem to have a clue, so please experiment.