====== QEMU: About native libraries bridge ======

A [[http://lists.gnu.org/archive/html/qemu-devel/2007-05/msg00318.html|mail]] on the QEMU development mailing-list reminded me of a proof-of-concept (PoC) I did 3 months ago. Native libraries support (henceforth ''nativelib'') in QEMU user-space linux emulation code. The initial goal was to have pthreads emulation for a linux/i386 user-space. The longer-term goal is broader and is beyond the scope of QEMU and is actually what I was working on (very sparsely!) the past 4 years through various experiments in nearly-inexistent spare time.

So, what's the status on the QEMU project side? Well, here is a [[this>projects/qemu/files/nativelib.tar.bz2|tarball]] and a [[this>projects/qemu/files/qemu-0.9.0-nativelib.patch|patch]] provided as is for the QEMU PoC. It passes the QEMU ''testthread'' test and bridges enough of ''libpthread'' and ''librt'' for that purpose. That implementation is weak insofar as nativelib lookup is really sub-optimal. Other implementations are meant to run-time patch ld.so, this provides more flexibily and permits to selectively nativelib a few functions (e.g. ''memcpy'' et al.), not the whole library.

** How to build?**

Please bear in mind this is just a PoC and is very incomplete in function coverage. If you still want to have a look, grab qemu 0.9.0 sources, preferably a 2007/02/14 snapshot, and apply both tarball and patch. Configure for a ''i386-linux-user'' target and ''make'' it. Then, in the ''i386-linux-user'' directory, delete the ''nativelib-*.so'' files and re-''make'' them with ''CC="gcc -m32"''. This assumes your host was x86_64. Otherwise, simply go to an i386 system and manually build the nativelibs.

**How does it work?**

  * Target libraries (here, linux/i386) are statically compiled with the functions reducing to a few assembly code: the //nativelib cookie//. The target libraries (e.g. ''nativelib-libpthread.so'') are placed in a special directory so that the ''open()'' syscall can actually resolve to this directory when target system libraries are looked up for.

  * The nativelib cookie is actually an illegal instruction (''0x0f 0x3c'') that is caught at code translation time. This illegal instruction is followed by two other instructions describing the native function to call (library code, function code). This could have been raw IDs but this makes debugging/disassembling trickier.

  * The ''do_nativelib()'' hook is then called and the library and function IDs are decoded and dispatched.

{{tag>linux emulation projects qemu}}