qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: axel <axel.zeuner@gmx.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code
Date: Sat, 17 Mar 2007 08:35:17 +0100	[thread overview]
Message-ID: <200703170835.18015.axel.zeuner@gmx.de> (raw)
In-Reply-To: <b2fa41d60703161230p631a886fp94906fcd51f71747@mail.gmail.com>

On Friday 16 March 2007 20:30, Igor Kovalenko wrote:
> On 3/16/07, Julian Seward <jseward@acm.org> 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

IMHO one should change dyngen. Below a hack (elf only, I can not test the COFF 
branch). It works for amd64->amd64 (tested with -no-kqemu), but is not save, 
because the instruction before the ret may contain the 0xf3 byte as immediate 
operand. 
A full solution would dissassemble the whole function, determine the borders 
of the opcode and then decide, where to cut the block to copy. Perhaps one 
could then also detect multiple returns in a function and one could try to 
rewrite the opcode blocks replacing the multiple returns with jumps.

Why there exist two different blocks for COFF and ELF for x86/x86_64 hosts?

Axel

Index: dyngen.c
===================================================================
RCS file: /sources/qemu/qemu/dyngen.c,v
retrieving revision 1.49
diff -u -r1.49 dyngen.c
--- dyngen.c    4 Mar 2007 00:52:16 -0000       1.49
+++ dyngen.c    17 Mar 2007 07:19:41 -0000
@@ -1458,6 +1458,8 @@
             error("empty code for %s", name);
         if (p_end[-1] == 0xc3) {
             len--;
+           if ( len>0 && p_end[-2] == 0xf3 )
+               --len;
         } else {
             error("ret or jmp expected at the end of %s", name);
         }

  parent reply	other threads:[~2007-03-17  7:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-16 14:15 [Qemu-devel] Redundant repz prefixes in generated amd64 code Julian Seward
2007-03-16 14:28 ` Paul Brook
2007-03-16 14:45   ` Julian Seward
2007-03-16 18:14     ` Paul Brook
2007-03-16 19:30 ` Igor Kovalenko
2007-03-16 23:06   ` Julian Seward
2007-03-17  7:35   ` axel [this message]
2007-03-17  9:51     ` Johannes Schindelin
2007-03-17 11:16       ` Axel Zeuner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703170835.18015.axel.zeuner@gmx.de \
    --to=axel.zeuner@gmx.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).