Re: How to clone CPUState in a new thread?

[Jakob Bohm]

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.
> In a nutshell, using ideas from unicorn-engine, I've enhanced 
> CPUARMState with a stop address. Whenever this address is encountered 
> in the translator, it generates a YIELD exception, which then makes 
> the cpu_loop to exit.
>
> It works fine for simple cases, but I'm having trouble with 
> multi-threading aspect. Threads created from the native/ARM side do 
> seem to work properly. The problem is when a new Java thread (not 
> created from native/ARM) attempts to execute native code. The QEMU 
> engine has been initialized in the main thread, but new Java threads 
> do not have access to thread-local variable thread_cpu.
>
> I've tried (maybe naively) to recreate what the clone syscall is doing 
> to create a new CPUState/CPUArchState object, usable from the new 
> thread, but executing any ARM code quickly lead to a crash. I suppose 
> I'm doing something wrong, or missing something to properly initiale a 
> new cpu. I'm hoping that someone could help me solve this problem.
>
> I've attached the current QEMU patch I'm using, most of the Android 
> glue layer is in linux-user/main.c. It contains a set of utility 
> functions that my Android native bridge implementation is using.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded