From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ig0Sc-0006VG-VF
	for qemu-devel@nongnu.org; Thu, 11 Oct 2007 12:00:31 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ig0Sa-0006SZ-OT
	for qemu-devel@nongnu.org; Thu, 11 Oct 2007 12:00:29 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ig0Sa-0006SM-Hn
	for qemu-devel@nongnu.org; Thu, 11 Oct 2007 12:00:28 -0400
Received: from relay01.mx.bawue.net ([193.7.176.67])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ths@networkno.de>) id 1Ig0SZ-0006M2-UI
	for qemu-devel@nongnu.org; Thu, 11 Oct 2007 12:00:28 -0400
Date: Thu, 11 Oct 2007 17:00:25 +0100
From: Thiemo Seufer <ths@networkno.de>
Subject: Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64
	bits targets
Message-ID: <20071011160025.GF3379@networkno.de>
References: <1192002128.9976.186.camel@rapid> <470C8AD9.6000002@bellard.org>
	<20071010174906.GC3379@networkno.de> <470D1C9A.2000505@bellard.org>
	<20071011151724.GD3379@networkno.de>
	<f43fc5580710110847v612b83ccu969803ebb743b5d6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f43fc5580710110847v612b83ccu969803ebb743b5d6@mail.gmail.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: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org

Blue Swirl wrote:
[snip]
> > >> I would think this feature will be limited to platforms which can handle
> > >> 32bit and 64bit binaries with a single personality.
> > >
> > > I am not sure it is a common case !
> > >
> > > However, I suggest to emulate a 32 bit user linux system with a 64 bit
> > > guest CPU running in 32 bit compatibily mode. It would be useful to test 64
> > > bit CPUs in 32 bit compatibility mode. The only required modification in
> > > linux user is to rename target_ulong so that it can have a different size
> > > of the CPU word default size.
> >
> > Doesn't work for MIPS64, since it doesn't quite have a compatibility mode
> > in the traditional sense. It needs to retain 64bit register width when
> > running N32 ABI binaries. (Thus the somewhat odd overrides I added for
> > the preliminary N32 support.)
> 
> CPU registers (and storage for full width registers) would still be 64
> bits. The ABI uses of target_ulong need to be changed to, for example
> abi_ulong so that the size can be changed.

I see.

> Sparc64 does not have a compatibility mode either (except for address
> masking), it can run Sparc32 binaries because of the cleverly designed
> instruction set. Ops use full 64 bits of a register, but there are two
> sets of CPU flags, 32 and 64 bits.

For MIPS it's not even that much, sign-extension magic handles everything.


Thiemo