On 3/16/07, Julian Seward <[EMAIL PROTECTED]> wrote:
I'm seeing redundant repz (0xF3) prefixes in generated code, typically just before jumps: <code_gen_buffer+415>: repz mov $0xe07f,%eax <code_gen_buffer+421>: mov %eax,0x20(%rbp) <code_gen_buffer+424>: lea -25168302(%rip),%ebx # 0xaf0420 <tbs+96> <code_gen_buffer+430>: retq <code_gen_buffer+431>: mov -25168245(%rip),%eax # 0xaf0460 <tbs+160> <code_gen_buffer+437>: jmpq *%rax <code_gen_buffer+439>: repz mov $0xe092,%eax <code_gen_buffer+445>: mov %eax,0x20(%rbp) <code_gen_buffer+448>: lea -25168325(%rip),%ebx # 0xaf0421 <tbs+97> <code_gen_buffer+454>: retq I assume these are something to do with translation chaining/unchaining but have been unable to figure out where they come from. I know they get executed are so are not data - valgrind barfs on them. This is on a 64-bit host (Core 2) with qemu-0.9.0 compiled from source by gcc-3.4.6, running an x86 (32-bit) guest. At a guess I'd say the mov $imm,%eax is (created by? to do with?) gen_jmp_im in target-i386/translate.c, but I don't see how the F3 got in on the act. Grepping the source for 0xF3 turns up nothing plausible. Any ideas where it comes from and how to get rid of it?
Try -mtune=nocona something like the following Index: Makefile.target =================================================================== RCS file: /cvsroot/qemu/qemu/Makefile.target,v retrieving revision 1.147 diff -u -r1.147 Makefile.target --- Makefile.target 28 Feb 2007 21:36:41 -0000 1.147 +++ Makefile.target 16 Mar 2007 19:29:04 -0000 @@ -99,6 +99,7 @@ endif ifeq ($(ARCH),x86_64) +OP_CFLAGS+= -mtune=nocona -W -Wall -O4 BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld endif -- Kind regards, Igor V. Kovalenko _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
