From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClvJC-0004se-CM for qemu-devel@nongnu.org; Tue, 04 Jan 2005 15:29:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClvJA-0004rI-02 for qemu-devel@nongnu.org; Tue, 04 Jan 2005 15:29:36 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClvJ9-0004qQ-09 for qemu-devel@nongnu.org; Tue, 04 Jan 2005 15:29:35 -0500 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Clv66-0000sq-RH for qemu-devel@nongnu.org; Tue, 04 Jan 2005 15:16:07 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Endian and userspace issues Date: Tue, 4 Jan 2005 20:16:03 +0000 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501042016.03910.paul@codesourcery.com> 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 Cc: anarkhos@vfemail.net On Tuesday 04 January 2005 19:44, anarkhos@vfemail.net wrote: > I became interested in QEMU when a Darwin port was revealed. > Unfortunately, user mode emulation isn't supported yet. However, even when > it is, I don't think (as I understand it) it will allow non-native binaries > (in either ELF or Mach-O format) to call native ones. I found it > interesting the documentation touts that user mode emulation can run WINE, > but the entire WINE set of libs would have to run under emulation. > > I understand that there is an inherent difficulty in that x86 executables > assume they are running in little endian mode (I call it mode since some > CPUs can run in either), but if one wants to have a shared user space with > one set of natively optimized libraries what better way to implement it? We > would have faster linking and faster CPU emulation. The problem is that to mix any two different types of code (big/little endian, native ppc vs emultated x86, whatever) you need a well defined interface between the two so that you can insert thunks. These thunks do whatever conversion is necessary. To do this you need to know all information passed across the interface. In practice this means not just the actual function arguments, but also any data passed/returned indirectly via pointers, and any data accessed via global variables. For userspace emulation the thunked interface is the linux syscall layer. This is designed to be a clean interface between two different types of code, so translating from guest syscalls to host syscalls is relatively simple. However shared libraries tend to have much less cleanly defined interfaces. They tend do share data structures, and be much more closely linked. This makes adding the translation layer between the two much more difficult, if not impossible. It generally requires designing the interface with this in mind from the start, and in general can't be retrofitted to existing libraries. Shared libraries (aka dlls) share an address space with the main application, so tend to be very hard to disentangle from each other. Paul