From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1DUvkl-0003c0-10
	for qemu-devel@nongnu.org; Sun, 08 May 2005 20:04:07 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1DUvkY-0003Tw-AE
	for qemu-devel@nongnu.org; Sun, 08 May 2005 20:03:56 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1DUvkU-0003Sh-FM
	for qemu-devel@nongnu.org; Sun, 08 May 2005 20:03:50 -0400
Received: from [62.89.75.144] (helo=bozon2.softax.com.pl)
	by monty-python.gnu.org with esmtp
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DUvi9-0002GE-0w
	for qemu-devel@nongnu.org; Sun, 08 May 2005 20:01:25 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by bozon2.softax.com.pl (Postfix) with ESMTP id 96587DC19A
	for <qemu-devel@nongnu.org>; Mon,  9 May 2005 01:55:15 +0200 (CEST)
Received: from bozon2.softax.com.pl ([127.0.0.1])
	by localhost (bozon2.softax.pl [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 10512-09 for <qemu-devel@nongnu.org>;
	Mon,  9 May 2005 01:55:11 +0200 (CEST)
Received: from zdzicha.k.local (dli52.neoplus.adsl.tpnet.pl [83.24.38.52])
	by bozon2.softax.com.pl (Postfix) with ESMTP id A564FDC04E
	for <qemu-devel@nongnu.org>; Mon,  9 May 2005 01:55:11 +0200 (CEST)
Content-Type: text/plain;
  charset="us-ascii"
From: Sebastian Kaliszewski <sk@z.pl>
Date: Mon, 9 May 2005 02:02:00 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200505090202.00547.sk@z.pl>
Subject: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0
Reply-To: sk@z.pl, 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

Hello!

As I understand the problem with dyngen & GCC 3.4 and newer is that even=20
when using the following marcro (line 158 of dynget-exec.h) in op_*=20
functions

#define FORCE_RET() asm volatile ("");

GCC still puts multiple exit points of a function.

But did anyone try the following one:

#define FORCE_RET() asm volatile ("" : : : "memory" );

This tells GCC that that asm block clobbers arbitrary memory. If it doesn=
t=20
help, then maybe putting few instructions will help (increasing the weigh=
t=20
of the code thus convincing optimiser not to multiplicate the asm block)?

#define FORCE_RET() asm volatile ("nop; nop; nop; nop" : : : "memory" );

or=20

#define FORCE_RET() asm volatile ("ret; ret; ret; ret" : : : "memory" );

Then if the above fails, then simply search the binary code for such bloc=
k=20
of fout instructions (in case of nops it'd be 0x90909090, in case of ret'=
s=20
-- don't remember). It's rather impossible, that such immediate value wou=
ld=20
apear inside op_* code, so the only real possibility is FORCE_RET()=20
occurence (Ther is also slim possibility that such code would be an align=
=20
fill block -- but AFAIR gcc is instructed ther not to align code and AFAI=
R=20
gcc would use block of 4 one byte nops -- it will use longer nops in such=
=20
cases). So then replacing such nops with jumps to end inside blocks is=20
trivial.

What do you think?

rgds
Sebastian Kaliszewski
--=20
"Never undersetimate the power of human stupidity" -- from notebooks of L=
=2EL.