qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Face Clock <faceclock@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Is it possible to use qemu to call a non-native library?
Date: Thu, 28 Oct 2010 09:45:58 +0100	[thread overview]
Message-ID: <AANLkTim3AEJ82UQGfcVL17EwCA7Bgz-SCuCdb-cnKSUk@mail.gmail.com> (raw)
In-Reply-To: <AANLkTim1Na4mVmAt-s2RMXQXBSUh__M6fC5vihryxYx-@mail.gmail.com>

On Thu, Oct 28, 2010 at 9:30 AM, Face Clock <faceclock@gmail.com> 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

      reply	other threads:[~2010-10-28  8:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-28  8:30 [Qemu-devel] Is it possible to use qemu to call a non-native library? Face Clock
2010-10-28  8:45 ` Stefan Hajnoczi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTim3AEJ82UQGfcVL17EwCA7Bgz-SCuCdb-cnKSUk@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=faceclock@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).