From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10406 invoked by alias); 29 Nov 2006 13:45:08 -0000 Received: (qmail 10395 invoked by uid 22791); 29 Nov 2006 13:45:07 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 29 Nov 2006 13:44:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1GpPjz-0007j2-CY; Wed, 29 Nov 2006 08:44:47 -0500 Date: Wed, 29 Nov 2006 13:45:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus , Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: Variable objects laziness Message-ID: <20061129134447.GA29365@nevyn.them.org> Mail-Followup-To: Vladimir Prus , Nick Roberts , gdb-patches@sources.redhat.com References: <17773.19183.730566.545997@kahikatea.snap.net.nz> <17772.60058.228181.835591@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17773.19183.730566.545997@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00380.txt.bz2 FWIW, I do think this counted as an obvious fix, but it's near the border indeed. And, Nick is right; Vladimir, please do add yourself to MAINTAINERS as write after approval. On Wed, Nov 29, 2006 at 10:25:11AM +0300, Vladimir Prus wrote: > > I think a further call to coerce_array is needed > > No, please no! Calls to coerce_array is exactly the reason for the other bug > I'm fixing. This function has a nice property of silently coercing_refs, > but that property is not documented, not obvious from function name and > therefore should be considered a bug. Let's please not change it though. Too much of GDB expects the current behavior... > Attached (references.diff) is the patch that makes gdb sense the changes in > reference values, and eliminates the address from the output. Any opinions? IMVHO, we should still print the value, but only update if the contents change; is that going to be a real pain to implement? > + /* If the value has changed, record it, so that next -var-update can > + report this change. If a variable had a value of '1', we've set it > + to '333' and then set again to '1', when -var-update will report this "then" rather than "when". Otherwise patch is fine. -- Daniel Jacobowitz CodeSourcery