From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1DSIDS-00053A-UJ
	for qemu-devel@nongnu.org; Sun, 01 May 2005 13:26:51 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1DSIDS-00052i-7V
	for qemu-devel@nongnu.org; Sun, 01 May 2005 13:26:50 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1DSI9h-0003Wh-LO
	for qemu-devel@nongnu.org; Sun, 01 May 2005 13:22:57 -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 1DSHwY-0001pd-L1
	for qemu-devel@nongnu.org; Sun, 01 May 2005 13:09:22 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.
Date: Sun, 1 May 2005 18:04:42 +0100
References: <1114859417.24014.59.camel@localhost.localdomain>
In-Reply-To: <1114859417.24014.59.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505011804.43687.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

On Saturday 30 April 2005 12:10, David Woodhouse wrote:
> GCC 4 occasionally generates functions with the 'blr' somewhere in the
> middle and a branch at the end.
>
> --- qemu-0.7.0/dyngen.c.orig	2005-04-30 11:59:05.000000000 +0100
> +++ qemu-0.7.0/dyngen.c	2005-04-30 12:00:11.000000000 +0100
> @@ -1396,11 +1395,13 @@ void gen_code(const char *name, host_ulo
>  #elif defined(HOST_PPC)
>      {
>          uint8_t *p;
> +        uint32_t insn;
>          p = (void *)(p_end - 4);
>          if (p == p_start)
>              error("empty code for %s", name);
> -        if (get32((uint32_t *)p) != 0x4e800020)
> -            error("blr expected at the end of %s", name);
> +        insn = get32((uint32_t *)p);
> +        if (insn != 0x4e800020 && (insn & 0xfc000002) != 0x48000000)
> +            error("blr or b expected at the end of %s", name);
>          copy_size = p - p_start;
>      }
>  #elif defined(HOST_S390)

This is not correct.
If the blr is not at the end of the function, things will break.
dyngen assumes the last instruction is the only return instruction in the 
function. This allows it to remove the blr insn and concatenate multiple 
functions together.

This basically only ever worked because gcc could be coerced into generating 
relatively simple code. GCC4 contains much more aggressive high level 
optimizers, so this is no longer possible.

Paul