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.
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...
r~
