Paul Brook wrote:
Notice the 'repz mov' sequence, which seems to be undocumented
instruction. It seems to work somehow but chokes valgrind decoder.
The following patch (against current CVS) fixes this problem,
This patch is incorrect.
It could match any number of other instructions that happen to end in 0xf3. eg
0: c7 45 00 00 00 00 f3 movl $0xf3000000,0x0(%ebp)
7: c3 ret
IIRC the "rep; ret" sequence is to avoid a pipeline stall on Athlon CPUs. Try
tuning for a different CPU.
Paul
Index: dyngen.c
===================================================================
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.40
diff -u -r1.40 dyngen.c
--- dyngen.c 27 Apr 2005 19:55:58 -0000 1.40
+++ dyngen.c 9 Nov 2005 19:12:38 -0000
@@ -1387,6 +1387,12 @@
error("empty code for %s", name);
if (p_end[-1] == 0xc3) {
len--;
+ /* This can be 'rep ; ret' optimized return sequence,
+ * need to check further and strip the 'rep' prefix
+ */
+ if (len != 0 && p_end[-2] == 0xf3) {
+ len--;
+ }
} else {
error("ret or jmp expected at the end of %s", name);
}
I was able to workaround 'rep ; ret' generation using gcc switches:
-mcpu=itanium2 -mtune=nocona
My system is running on amd64 and gcc required both -mcpu and -mtune
--
Kind regards,
Igor V. Kovalenko
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
