From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1793 invoked by alias); 19 Sep 2007 15:03:49 -0000 Received: (qmail 1783 invoked by uid 22791); 19 Sep 2007 15:03:49 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Sep 2007 15:03:45 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8JF3gJ7028833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Sep 2007 11:03:42 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8JF3gQB032695 for ; Wed, 19 Sep 2007 11:03:42 -0400 Received: from toothpaste.toronto.redhat.com (toothpaste.toronto.redhat.com [172.16.14.161]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l8JF3f0W002579 for ; Wed, 19 Sep 2007 11:03:42 -0400 Message-ID: <46F13A4D.5090408@redhat.com> Date: Wed, 19 Sep 2007 15:03:00 -0000 From: Teresa Thomas User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: frysk Subject: Re: minutes of 2007-09-19 meeting References: <46F13329.6000406@oracle.com> In-Reply-To: <46F13329.6000406@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00397.txt.bz2 > Teresa: > OP_Piece: it's working for registers and memory as far as we know. Not > turned on yet. Sami reports that testing with that enabled results in > better test results. The location code correctly decodes the location of the values, whether in memory, register or with a memory split. Facing two problems with manipulating variable values, (1) Getting variable values does not return expected value in 32 bit machines though it does this for x86_64. Examining the memory of the task in a 32-bit machine shows that it contains the LSB of the value at the decoded location, but the the bytes that follow are random. (2) Frame's setReg does not change the value of the register. So setting values is possible in memory but not regs. Its probably not a good idea to enable the new location code atleast till (1) is fixed.