From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HVyCx-00006k-RX
	for qemu-devel@nongnu.org; Mon, 26 Mar 2007 19:02:35 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HVyCu-00006E-FT
	for qemu-devel@nongnu.org; Mon, 26 Mar 2007 19:02:35 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HVyCu-00006B-7Z
	for qemu-devel@nongnu.org; Mon, 26 Mar 2007 18:02:32 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1HVyAb-0000aX-5X
	for qemu-devel@nongnu.org; Mon, 26 Mar 2007 19:00:09 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64
	-no-kqemu) compiles with gcc4 and works
Date: Mon, 26 Mar 2007 23:53:23 +0100
References: <200703241850.03116.axel.zeuner@gmx.de>
	<460709E4.3010907@codemonkey.ws>
	<200703260749.09384.axel.zeuner@gmx.de>
In-Reply-To: <200703260749.09384.axel.zeuner@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200703262353.24625.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
Cc: Axel Zeuner <axel.zeuner@gmx.de>

> > I moved to helper2.c because AFAICT helper.c is compiled with the same
> > sort of restrictions as op.c which leads to the compile failure.
>
> Yes, helper.c is compiled with the global register variables and the code
> is called directly from the op_xxx functions, but one needs the global
> register variables to access global data, these contain the required
> environment for the emulation. AFAIK helper2.c is used by the CODE_COPY
> branch on i386 with even stronger restrictions, but I may be wrong here.

helper.c is compiled with the same setting as op.c, so has direct access to 
the dyngen state ("T0", "env" etc). helper2.c is regular code. Either may be 
used from op.c, the difference is whether all arguments are explicit. Also, 
if a helper throws an exception it must be in helper.c to avoid clobbering 
CPU state before calling raise_exception.

Note that some targets use a different naming scheme. They use helper.c for 
regular code and op_helper.c for op.c-like code. IMHO this is a much better 
naming scheme.

Paul