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.
