[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Endian and userspace issues
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] Endian and userspace issues |
Date: |
Tue, 4 Jan 2005 20:16:03 +0000 |
User-agent: |
KMail/1.7.1 |
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] Endian and userspace issues, anarkhos, 2005/01/04
- Re: [Qemu-devel] Endian and userspace issues,
Paul Brook <=
- Re: [Qemu-devel] Endian and userspace issues, anarkhos, 2005/01/04
- Re: [Qemu-devel] Endian and userspace issues, John Davidorff Pell, 2005/01/04
- Re: [Qemu-devel] Endian and userspace issues, anarkhos, 2005/01/04
- Message not available
- Re: [Qemu-devel] Endian and userspace issues, Karl Magdsick, 2005/01/05
- Re: [Qemu-devel] Endian and userspace issues, Gwenole Beauchesne, 2005/01/05
- Re: [Qemu-devel] Endian and userspace issues, Daniel Egger, 2005/01/05
- Re: [Qemu-devel] Endian and userspace issues, Magnus Damm, 2005/01/05
- Re: [Qemu-devel] Endian and userspace issues, Daniel Egger, 2005/01/05