From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22404 invoked by alias); 17 Nov 2006 15:01:11 -0000 Received: (qmail 22395 invoked by uid 22791); 17 Nov 2006 15:01:11 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Nov 2006 15:01:00 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gl5D1-0006qV-C0 for gdb-patches@sources.redhat.com; Fri, 17 Nov 2006 16:00:52 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 16:00:51 +0100 Received: from vladimir by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 16:00:51 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: Variable objects laziness Date: Fri, 17 Nov 2006 15:01:00 -0000 Message-ID: References: <200611141643.25053.vladimir@codesourcery.com> <20275.192.87.1.22.1163760030.squirrel@webmail.xs4all.nl> <200611171344.54155.vladimir@codesourcery.com> <20061117142230.GA29258@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00166.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Nov 17, 2006 at 01:44:53PM +0300, Vladimir Prus wrote: >> On Friday 17 November 2006 13:40, Mark Kettenis wrote: >> > > Daniel Jacobowitz wrote: >> > > > Sorry, you're right! >> > > > >> > > > When you're ready, please repost. Might want to finish talking >> > > > with Nick first. >> > >> > As Nick indicated, I'm not sure whether the removal of my_value_equal >> > is ok. The whole point of my_value_equal is to check equality of values >> > without error()ing out if we can't read a value. Your replacement code >> > doesn't seem to take that possibility into account. >> >> Are you sure? The code has exactly one place where value is fetched, and >> it does that by the call to gdb_value_fetch_lazy -- that calls >> value_fetch_lazy in a try block. Any errors will be caught and cause the >> value to be set to NULL. > > I think this is the key bit - my_value_equal called value_fetch_lazy, > the new code calls gdb_value_fetch_lazy. > > Vlad, I noticed that the old code used coerce_array and the new one > doesn't. Is that a problem? This should not be a problem on -var-update path, because we never try to compare values of array types, since for them type_changeable returns false. However, it looks to be a problem on -var-assign path. Given: int b[] = {1,2,3}; int *a = b; if we create varobj for 'a' and assign it the value of 'b', we should not mark this variable as changed. I'll double-check this (and other coercions that coerce_array silently does) and add new test cases as needed. Thanks, Volodya