[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to clone CPUState in a new thread?

From: Michael Goffioul
Subject: Re: How to clone CPUState in a new thread?
Date: Fri, 8 Nov 2019 20:08:47 -0500

On Thu, Nov 7, 2019 at 1:50 PM Michael Goffioul <address@hidden> wrote:
On Thu, Nov 7, 2019 at 7:53 AM Peter Maydell <address@hidden> wrote:
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?

It turned out the problem was really the lack of TLS storage initialization in the emulated code. In particular, Android P and lower uses one of the 8 TLS slots defined in bionic to manage errno, meaning that any system call would most likely lead to a crash. With some trickery, I manage to initialize the emulated side of the thread properly and the code then runs fine.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]