From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KffQm-00068l-C1
	for qemu-devel@nongnu.org; Tue, 16 Sep 2008 14:37:44 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KffQk-00068L-VD
	for qemu-devel@nongnu.org; Tue, 16 Sep 2008 14:37:44 -0400
Received: from [199.232.76.173] (port=53778 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KffQk-00068I-OK
	for qemu-devel@nongnu.org; Tue, 16 Sep 2008 14:37:42 -0400
Received: from mail-gx0-f19.google.com ([209.85.217.19]:54064)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1KffQk-0000Ux-HL
	for qemu-devel@nongnu.org; Tue, 16 Sep 2008 14:37:42 -0400
Received: by gxk12 with SMTP id 12so26575193gxk.10
	for <qemu-devel@nongnu.org>; Tue, 16 Sep 2008 11:37:41 -0700 (PDT)
Message-ID: <f43fc5580809161137t819cb9ehd94b8c2be1b253@mail.gmail.com>
Date: Tue, 16 Sep 2008 21:37:41 +0300
From: "Blue Swirl" <blauwirbel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [Qemu-devel] env fields as TCG variables
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel <qemu-devel@nongnu.org>

I wonder if the following bug scenario is possible.

Some of the env fields are accessible as TCG variables, like cpu_fsr
for Sparc floating point status register (%fsr), stored in the env
structure field env->fsr. When cpu_fsr is used in the generated code,
a host CPU register is allocated for this task. But env->fsr can be
modified directly in op_helper.c code. Isn't it then possible that the
register (which stores cpu_fsr) and the structure field in memory
(env->fsr) get out of sync?

If this is true, no code outside the generated code should ever modify
or even read env fields that are also available as TCG variables. Or
do I miss something?