[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 01/12] ARM: Export cpu_env

From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v2 01/12] ARM: Export cpu_env
Date: Fri, 28 Jun 2013 16:42:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

Am 28.06.2013 16:35, schrieb Peter Maydell:
> On 28 June 2013 15:28, Andreas Färber <address@hidden> 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?


SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

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