On Thu, Nov 7, 2019 at 7:38 AM Michael Goffioul <michael.goffi...@gmail.com> wrote:
> > > On Thu, Nov 7, 2019 at 4:57 AM Jakob Bohm <jb-gnumli...@wisemo.com> wrote: > >> On 07/11/2019 01:44, Michael Goffioul wrote: >> > Hi, >> > >> > I'm working on a project that wants to replace houdini (ARM-to-x86 >> > translation layer for Android from Intel) with a free open-source >> > implementation. I'm trying to leverage qemu user-mode to achieve that, >> > but it requires code changes to allow executing dynamically loaded >> > functions instead of running a single executable. >> > >> Basic question: Isn't the qemu user-mode emulator already able to run a >> "single executable" that loads DLLs, creates dynamic code etc. in the >> emulated instruction set? >> >> The obvious exception would be to skip the ARM instruction set >> intermediary >> when translating Dalvik byte code from .dex files. >> >> From this perspective, emulated ARM thread creation would be just letting >> qemu emulate the ARM code that would be called, including letting qemu >> emulate >> the system calls such as "clone". >> >> A special case would be if houdini allows direct calls between ARM and x86 >> .so files. I don't know if qemu-user has the ability to expose host >> native DLLs to emulated code. >> > > Basically Houdini implements the native bridge interface, as defined here: > https://android.googlesource.com/platform/system/core/+/refs/tags/android-10.0.0_r11/libnativebridge/include/nativebridge/native_bridge.h#172 > It allows running Android APK that contains ARM-compiled native/JNI code > on an Android-x86 OS. It does so by taking care of loading the ARM .so JNI > files are providing trampoline stubs to the Android runtime JVM. It does > not expose the host native .so to the emulated code, instead it provides a > set of ARM-compiled core libraries from Android: it is actually very > similar to running dynamically linked code in qemu-user with a chroot'ed > ARM environment. Actual interaction with the native host is happening > mostly/only through binder socket. > > To initialize the qemu-user engine, I make it load a custom ARM .so/ELF > file that uses the Android linker (from the ARM pseudo chroot environment) > as interpreter. This allows me to delegate all dynamic linking aspects. > > So far, the emulation is working fine and I'm able to run simple > ARM-compiled apps on Android-x86, even if the native code spawns new > threads. My current (hopefully last) problem is when a Java thread, > different than the one that initialized the qemu engine) is trying to run > native code. I need to setup a new CPUState/CPUArchState instance for this > Java thread. > Side question: is this the right mailing list to discuss this, or is there a more appropriate one?
