[Qemu-devel] Compilation broken in SVN version and a debug register question

[Balazs Attila-Mihaly \(Cd-MaN\)]

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 <variable>._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?

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?

Thank you in advance for your time spent answering my questions.

Best regards.




      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html