From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUhJy-0001Tp-6A for qemu-devel@nongnu.org; Sun, 27 Nov 2011 11:11:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUhJx-0002bC-4i for qemu-devel@nongnu.org; Sun, 27 Nov 2011 11:11:14 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54200 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUhJw-0002b0-Mc for qemu-devel@nongnu.org; Sun, 27 Nov 2011 11:11:12 -0500 Message-ID: <4ED260FA.6020701@suse.de> Date: Sun, 27 Nov 2011 17:10:34 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <4ED24545.1060902@suse.de> <4ED24EF7.4050704@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] cpu_regs in target-i386 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xin Tong Cc: qemu-devel Am 27.11.2011 16:23, schrieb Xin Tong: > This is a bit confusing then >=20 > in target-i386/translate.c >=20 > void optimize_flags_init(void) > { > ... > cpu_regs[15] =3D tcg_global_mem_new_i64(TCG_AREG0, > offsetof(CPUState, regs[15]),= "r15"); > printf("offsetof(CPUState, regs[15]) is %ld\n", offsetof(CPUState, re= gs[15])); >=20 > ... > } >=20 > output is cpu_regs[15] is 20, offsetof(CPUState, regs[15]) is 120, > should not cpu_regs[15] =3D=3D 120 ? Please don't top-post, your reply is out of context then. See below. > On Sun, Nov 27, 2011 at 9:53 AM, Andreas F=E4rber wr= ote: >> Am 27.11.2011 15:36, schrieb Xin Tong: >>> If i understand correctly here, those are just array of offsets for >>> the emulated registers such that the tcg can easily get access to the >>> address of the emulated registers. This is, however, different from >>> the env (CPUx86State) variable which will always have a host register >>> pointing to it ( host register is made to point to env in the tb ente= r >>> prologue). >> >> Yes: >> >> host register pointed to by cpu_env contains address of env >> + >> offset stored in cpu_* variable Note that "variable" refers to TCG variable (TCGv), not C variable, cf. tcg/README. If you do printf("%d", cpu_xyz), you will only see the internal ID of that variable that points to data stored elsewhere. In this case the ID happens to be constant because these are set up once during target initialization. >> =3D >> address of corresponding struct member in env When playing with TCG, configure with --enable-debug-tcg, then the definitions are changed so that the compiler can make you aware of such mixups. Andreas >>> On Sun, Nov 27, 2011 at 9:12 AM, Andreas F=E4rber = wrote: >>>> Am 27.11.2011 14:46, schrieb Xin Tong: >>>>> When the x86 vcpu is initialized, a CPUX86State is qemu_mallocz'ed. >>>>> env is used to point to it and modifications to the CPUX86State can >>>>> thereby be done via the register that contains the env. I do not ge= t >>>>> what the cpu_regs[CPU_NB_REGS] are for, do not we already have a se= t >>>>> of emulated x86 registers when we allocate the CPUX86State ? >>>> >>>> I assume in i386, too, it will be a TCGv array and will be initializ= ed >>>> to point to individual memory offsets inside CPU*State. >>>> So they're for convenience and readability. --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg