Re: [Qemu-devel] Endian and userspace issues

[Paul Brook <paul@codesourcery.com>]

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