From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1CG9uz-0001AY-5a
	for qemu-devel@nongnu.org; Sat, 09 Oct 2004 01:37:21 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1CG9uy-0001AM-PT
	for qemu-devel@nongnu.org; Sat, 09 Oct 2004 01:37:20 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1CG9uy-0001AJ-Lj
	for qemu-devel@nongnu.org; Sat, 09 Oct 2004 01:37:20 -0400
Received: from [195.130.132.58] (helo=astra.telenet-ops.be)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1CG9nn-00078I-E1
	for qemu-devel@nongnu.org; Sat, 09 Oct 2004 01:29:55 -0400
Subject: Re: [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host
From: Bob Deblier <bob.deblier@telenet.be>
In-Reply-To: <cd8ecdef04100817224ea0b06c@mail.gmail.com>
References: <1097175246.2833.51.camel@orion>
	<cd8ecdef04100817224ea0b06c@mail.gmail.com>
Content-Type: text/plain
Message-Id: <1097299793.2834.18.camel@orion>
Mime-Version: 1.0
Date: Sat, 09 Oct 2004 07:29:53 +0200
Content-Transfer-Encoding: 7bit
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: Karl Magdsick <kmagnum@gmail.com>, qemu-devel@nongnu.org

On Sat, 2004-10-09 at 02:22, Karl Magdsick wrote:
> What is your compiler target when creating the qemu executible?

Native, i.e. x86_64-linux-gnu.

> My understanding is that almost all of the instructions in 64-bit mode
> are reverse-compatible with 32-bit mode, but a few have changed
> slightly.  If your qemu executible is compiled for 64-bit mode (and is
> therefore being run in 64-bit usermode), but the jit is generating
> 32-bit code, this could be problematic for a small number of
> instructions.  I have no direct knowledge of the differences between
> the instruction encodings for 32-bit and 64-bit modes, just hearsay.
> 
> Just a guess.

>>From looking at the code, I don't get the impression that that's the
case. It may just be that some of the code isn't 64-bit clean, i.e. that
there are places where the coders have assumed that sizeof(pointer) = 4,
etc.

More investigating *sigh*

Bob