From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1DUyA8-0007qo-Nx
	for qemu-devel@nongnu.org; Sun, 08 May 2005 22:38:28 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1DUyA7-0007pg-I0
	for qemu-devel@nongnu.org; Sun, 08 May 2005 22:38:28 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1DUyA7-0007o1-0f
	for qemu-devel@nongnu.org; Sun, 08 May 2005 22:38:27 -0400
Received: from [65.74.133.9] (helo=mail.codesourcery.com)
	by monty-python.gnu.org with esmtp
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DUyBb-0008Pd-AF
	for qemu-devel@nongnu.org; Sun, 08 May 2005 22:39:59 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0
Date: Mon, 9 May 2005 03:33:34 +0100
References: <200505090202.00547.sk@z.pl> <200505090140.57249.paul@nowt.org>
	<200505090355.24247.sk@z.pl>
In-Reply-To: <200505090355.24247.sk@z.pl>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505090333.35255.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, sk@z.pl

On Monday 09 May 2005 02:55, Sebastian Kaliszewski wrote:
> So the idea was indeed stupid :)
>
> On Monday 09 May 2005 02:40, Paul Brook wrote:
> > No. The main problem with gcc3.4 was that we weren't using FORCE_RET
> > everywhere that we should. This has mostly been fixed now.
>
> I see...
>
> [snip]
>
> > I've got a solution for x86/x86-64 that's 95% complete, using the method
> > I suggested in a previous email.
>
> So, since ret is too small to be replaced with jump, you relocate the block
> following ret few bytes further, and retarget all relevant jumps?

Almost. I relocate the instructins immediately preceeding the ret. I define 
FORCE_RET()  as "nop; nop; nop; nop" to make sure we always have some code 
that can be moved without having to relocate any jumps. In most cases dyngen 
can then recognise these nop blocks, and remove them from the output.

Paul