On Mon, Mar 26, 2012 at 16:52, Richard Henderson <r...@twiddle.net> wrote: > On 03/26/12 09:31, Blue Swirl wrote: >>> > +/* In dyngen-exec.h, without AREG0, we fall back to an alias to >>> > cpu_single_env. >>> > + We can't actually tell from here whether that's needed or not, but it >>> > does >>> > + not hurt to go ahead and make the declaration. */ >>> > +#ifndef CONFIG_TCG_PASS_AREG0 >>> > +extern >>> > +#ifdef __linux__ >>> > + __thread >>> > +#endif >>> > + CPUArchState *env __attribute__((alias("tls__cpu_single_env"))); >>> > +#endif /* CONFIG_TCG_PASS_AREG0 */ >> Please use DECLARE_TLS/DEFINE_TLS and global env accesses should also >> use tls_var(). >> > > That won't work. > > This is intended to be a drop-in replacement for the "env" symbol that > we declare in dyngen-exec.h. For all other hosts, this symbol is a > global register variable. We can't go wrapping tls_var around all uses > in all target backends. > > As I say in the comment, the most natural replacement is a preprocessor > macro, but then that fails with the uses of "env" in the DEF_HELPER_N > macros. > > Which leaves no alternative -- short of converting *all* targets to > CONFIG_TCG_PASS_AREG0 first -- except the symbol alias you see there.
But at that point there will be no global env use anymore, so dyngen-exec.h etc. can be removed. Perhaps this patch and its dependencies should wait for that to happen. As an intermediate hack it's sort of OK. > Hmm... actually... I'm wrong about the use of preprocessor macros. > The simple solution there is to re-order the includes on a few ports. > I.e. "helper.h" must come before "dyngen-exec.h". Now that's a much > simpler fix... OK. > > > r~