Am 28.06.2013 16:35, schrieb Peter Maydell: > On 28 June 2013 15:28, Andreas Färber <afaer...@suse.de> wrote: >> I don't mind that cpu_env change getting committed as interim solution, >> so far I did not come up with a better patch - we'd need to split out >> host parts from tcg/tcg.h first, for which I did not find time yet. > > Interim solution on the path to where? I'm not convinced the > cpu_env variables should be visible outside each individual > decoder (any more than, for instance, the ARM cpu_V0, cpu_V1 > variables are). Admittedly the environment pointer is a bit > of a special case, but perhaps we should deal with it by making > it less of one?
Well, I'm not so fond of the idea of having two static variables for the same thing. If that is just to shield the global symbols, we could rename the exported variable to arm_cpu_env and do #define cpu_env arm_cpu_env to avoid a large-scale renaming. I was thinking that the only thing this duplicated TCGv_ptr cpu_env depends on is host pointer size, TCG debug configuration (struct or integer) and host environment pointer register. So why duplicate it longterm rather than having one that can be shared by multiple targets to derive the target-specific register TCGv* variables? Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
