[Qemu-devel] x86_64 vs. i386

[Qemu-devel] x86_64 vs. i386

[Philipp Gühring]

Hi,

The current Linux distributions for x86_64 can run both 64Bit and 32Bit 
applications. But they have one major problem: 64Bit applications have to use 
64Bit libraries, and 32Bit applications have to use 32Bit libraries.

One huge problem for example is the non-existance of a 64Bit Flash-Player at 
the moment.

Those are the usual error message for 32 vs. 64 bit problems

/usr/lib/firefox/firefox-bin: error while loading shared libraries: 
libasound.so.2: wrong ELF class: ELFCLASS64

Inconsistency detected by ld.so: dl-close.c: 342: _dl_close: Assertion 
`tmap->l_ns == ns' failed!

Now I am wondering, whether it would be possible to integrate the processor 
emulator of qemu into the Linux kernel, so that applications can 
transparently use different-bitsized libraries by qemulating them on demand?

Best regards,
Philipp Gühring

Re: [Qemu-devel] x86_64 vs. i386

[Thomas Steffen]

On 7/31/06, Philipp Gühring <pg@futureware.at> wrote:
[32bit vs 64bit libraries]
> Now I am wondering, whether it would be possible to integrate the processor
> emulator of qemu into the Linux kernel, so that applications can
> transparently use different-bitsized libraries by qemulating them on demand?

The problem is not running 32bit code, a 64bit kernel can do that
perfectly fine (with the correct 32bit libraries). The problem is that
32bit and 64bit code has a different ABI. Basically, if you call a
library function with an integer on the pointer, both are put on the
stack. In the 32bit ABI, they are both 4 byte values, but in the 64bit
ABI the pointer needs 8 bytes.

So when you want to call 64bit libraries from 32bit code, you would
need to convert the parameters on the stack, and for that you would
need to know what the parameters are. However, the library and the
code have no information on this, because it is only in the source
code, not in the binary.

There are more problems (address space, different register allocation
etc), but the function call sequence is the main problem. And qemu
cannot solve it.

Thomas