Re: [Qemu-devel] Is it possible to use qemu to call a non-native library?

[Stefan Hajnoczi]

On Thu, Oct 28, 2010 at 9:30 AM, Face Clock <address@hidden> wrote:
> I am new to QEMU and have a question.
>
> I know QEMU can be used to run a program (user mode emulation) or boot
> a system (full system emulation). But can I use QEMU to load from a
> program a shared library (such as .so file in linux) which was built
> for a different CPU target?
>
>  For instance, I have a program prog_a, which run on one type of CPU.
> prog_a  needs a dynamic library b.so. But the b.so at hand is meant
> for a different CPU (non-native). To use b.so, can I do this:  prog_a
> --> QEMU emulation --> b.so?  In this sense, the emulation is done at
> the API/library level, not at  the program or system level.
>
> Is it possible?I am willing to change QEMU code to do this.

That cannot be done in an automated way because the non-native library
functions may operate on arbitrary inputs/outputs.  QEMU doesn't know
the structure of data in memory so it cannot handle
endianness/alignment differences.

struct date {
    int month;
    int day;
    int year;
};

int format_date(const struct date *date, char *buf, size_t len);

When native code calls that function with a pointer to struct date,
you need to convert the native struct date to the non-native struct
date.  That may involve byteswapping, it could involve alignment
differences too.

One way to do this is by writing a proxy native library that converts
and forwards all calls to the non-native library.  The non-native
library can be loaded by a non-native stub program running under QEMU
user emulation:
native program <- links against -> native proxy library <-
communicates with -> non-native stub program <- links against ->
non-native library

This is kind of how nspluginwrapper works AFAIK.  You may be able to
simplify the indirection a bit if you can integrate QEMU into the
native proxy library directly.

Stefan