From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JP4a7-0006LB-AU
	for qemu-devel@nongnu.org; Tue, 12 Feb 2008 18:30:31 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1JP4a5-0006KI-LA
	for qemu-devel@nongnu.org; Tue, 12 Feb 2008 18:30:30 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JP4a5-0006K7-BS
	for qemu-devel@nongnu.org; Tue, 12 Feb 2008 18:30:29 -0500
Received: from relay3-v.mail.gandi.net ([217.70.178.77])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <fabrice@bellard.org>) id 1JP4a5-0002Ky-11
	for qemu-devel@nongnu.org; Tue, 12 Feb 2008 18:30:29 -0500
Message-ID: <47B22BE0.1020306@bellard.org>
Date: Wed, 13 Feb 2008 00:29:36 +0100
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
References: <C1F64311-F19D-4A9B-8150-F12ABCAF41D5@csgraf.de>
In-Reply-To: <C1F64311-F19D-4A9B-8150-F12ABCAF41D5@csgraf.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [RESEND] TCG breakage if TARGET_LONG_BITS >
	HOST_LONG_BITS
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: Alexander Graf <alex@csgraf.de>

Alexander Graf wrote:
> This is a resend of a mail I sent to the list on 2008/02/06. I felt it
> rather disturbing, yet normal that nobody cared about Mac OS X host
> support, but this concerns all x86 host OSs, so I believe this deserves
> some discussion.
> 
> Hi,
> 
> I've been trying to get the new TCG approach running on an i386 host. It
> works when I use gcc3 (miraculously as I will explain later), but fails
> on gcc4.
> 
> On boot the very first instruction that gets issued is the ljmp to the
> bios:
> [...]
> 1. Why is gcc3 generating code, that does not use ebx?
> 2. Why does movi_i64 generate code that only accesses registers? I have
> not been able to find any branch in the tcg code generator for movi_ixx
> that generates movs to memory addresses.
> 
> The whole issue could be easily fixed by using registers, but putting
> the call into inline assembly, telling gcc that this call clobbers all
> the registers. I do not know if this is the expected behavior though, so
> I think I'd rather ask before doing any patches.

The fact that it works in some cases is a miracle. The right solution is
to use a global TB prologue and epilogue which saves and restores callee
saved registers (it is in the tcg TODO list).

A temporary solution before that would be to mark ebx, esi and edi as
reserved registers if TARGET_LONG_BITS > HOST_LONG_BITS.

Fabrice.