From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ig0G5-0006ni-LU for qemu-devel@nongnu.org; Thu, 11 Oct 2007 11:47:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ig0G4-0006nL-8U for qemu-devel@nongnu.org; Thu, 11 Oct 2007 11:47:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ig0G4-0006nI-32 for qemu-devel@nongnu.org; Thu, 11 Oct 2007 11:47:32 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ig0G3-0002Uk-Lc for qemu-devel@nongnu.org; Thu, 11 Oct 2007 11:47:31 -0400 Received: by nf-out-0910.google.com with SMTP id 30so562965nfu for ; Thu, 11 Oct 2007 08:47:30 -0700 (PDT) Message-ID: Date: Thu, 11 Oct 2007 18:47:29 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets In-Reply-To: <20071011151724.GD3379@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1192002128.9976.186.camel@rapid> <470C8AD9.6000002@bellard.org> <20071010174906.GC3379@networkno.de> <470D1C9A.2000505@bellard.org> <20071011151724.GD3379@networkno.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 10/11/07, Thiemo Seufer wrote: > Fabrice Bellard wrote: > > Thiemo Seufer wrote: > >> Fabrice Bellard wrote: > >>> J. Mayer wrote: > >>>> Following the patches done for elfload32, it appeared to me that there > >>>> were still problems that would prevent 32 bits executables to run on 64 > >>>> bits target in linux user mode emulation. > >>>> [...] > >>> Are you sure it is a good idea to try to add 32 bit executable support to > >>> a 64 bit target ? In the end you will need to write a 64 bit to 32 bit > >>> linux syscall converter which would mean duplicating all the linux-user > >>> code of the corresponding 32 bit target (think of ioctls with strutures, > >>> signals frames, etc...). > >> 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. 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.