Re: [Qemu-devel] Endian and userspace issues

[John Davidorff Pell]

I think that part of what he is suggesting is that the code that is 
little endian be translated to Big endian before execution. This would 
make the running binary "native" in memory, and so could continue to be 
closely integrated with its linked libraries.

I'd also like to note that WINE does load binaries that are linked to a 
number of libraries with no officially documented interface but manages 
to handle things rather well. Granted they don't have to deal with 
endian issues. :-)

JP

On 4 Jan 2005, at 12:16, Paul Brook wrote:

> On Tuesday 04 January 2005 19:44, address@hidden 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
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
When life hands you lemons, ask for a bottle of gin and tonic.

smime.p7s
Description: S/MIME cryptographic signature