Re: [Qemu-devel] [PATCH] tcg: Reload local variables after return from longjmp

[Paolo Bonzini <pbonzini@redhat.com>]

On 08/11/2011 03:31 PM, Peter Maydell wrote:
>>>
>>> Then it's a compiler bug, not smartness.  Making env volatile
>>> (or making a volatile copy if there is a performance impact)
>>> should still be enough to work around it.
> Yes. (It would have to be a volatile copy, I think, env is a function
> parameter and I don't think you can make those volatile.)
> https://bugs.launchpad.net/qemu/+bug/823902  includes some discussion
> of the effects on the test of adding the volatile copy.

I'm not sure about what to read from there:

> If I make cpu_single_env thread local with __thread and leave
> 0d101... in, then again it works reliably on 32bit Lucid, and is
> flaky on 64 bit Oneiric (5/10 2 hangs, 3 segs)
>
> I've also tried using a volatile local variable in cpu_exec to hold
> a copy of env and restore that rather than cpu_single_env. With this
> it's solid on 32bit lucid and flaky on 64bit Oneirc; these failures
> on 64bit OO look like it running off the end of the code buffer (all
> 0 code), jumping to non-existent code addresses and a seg in
> tb_reset_jump_recursive2.

It looks like neither a thread-local cpu_single_env nor a volatile copy 
fix the bug?!?

I cannot think off-hand of a reason why thread-local cpu_single_env 
should not work for iothread under Unix, BTW.  Since cpu_single_env is 
only set/used by a thread at a time (under the global lock), its users 
cannot distinguish between a thread-local variable and a global.

The only problem would be Windows, which runs cpu_signal in a thread 
different than the CPU thread.  But that can be fixed easily in 
qemu_cpu_kick_thread.

Paolo