On Thu, 7 Nov 2019 at 12:46, Michael Goffioul
<address@hidden> wrote:
> Side question: is this the right mailing list to discuss this, or is there a more appropriate one?
You're more likely to find actual QEMU developers reading qemu-devel;
qemu-discuss has fewer contributors and they tend to be more
likely to be end-users or interested in end-user questions
rather than internals.
As for your original question, if you're creating a new
thread and want the new thread's TCG CPU state to match
that of the old thread then the linux-user 'clone' call
is what you want to follow. Duplicating the existing CPU
state is a bit of a hacky codepath but it does work.
If you have a thread that doesn't want to follow the
existing CPU state of some other creating thread but
instead is started with a fixed entirely-known state,
then the code in linux-user/main.c which starts the first
thread of the process might be a better model.
Overall, though, QEMU's code is not designed to be embedded
into some other runtime environment in the way you're doing
it, so I would expect there to be pain involved in trying
to get it to work (especially surrounding threads, new
processes and signals).
Thanks for the input. I've feeling that the problem is related to the stack setup for the emulated code, or better, the lack thereof. I've successfully run JNI code in a separate java thread, while still originally loaded and tcg-processed in the main thread, for things like integer computation or even creating and returning a Java string. However something like sending a string to logcat makes the thing crash. The primary suspect is the TLS, which, if I'm not mistaken, is located somewhere in the thread's stack. Would that make sense?