From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29717 invoked by alias); 4 Jan 2007 21:00:14 -0000 Received: (qmail 29695 invoked by uid 22791); 4 Jan 2007 21:00:12 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 Jan 2007 21:00:03 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H2Zgp-000610-9D for gdb-patches@sources.redhat.com; Fri, 05 Jan 2007 00:00:00 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1H2ZgZ-00060K-AW; Thu, 04 Jan 2007 23:59:39 +0300 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: RFC: MI - Detecting change of string contents with variable objects Date: Thu, 04 Jan 2007 21:00:00 -0000 User-Agent: KMail/1.9.1 Cc: Nick Roberts , gdb-patches@sources.redhat.com References: <17798.19683.251190.740216@kahikatea.snap.net.nz> <17821.25837.573239.858406@kahikatea.snap.net.nz> <20070104205039.GH24634@nevyn.them.org> In-Reply-To: <20070104205039.GH24634@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701042358.59475.ghost@cs.msu.su> 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: 2007-01/txt/msg00143.txt.bz2 On Thursday 04 January 2007 23:50, Daniel Jacobowitz wrote: > On Fri, Jan 05, 2007 at 09:34:53AM +1300, Nick Roberts wrote: > > > Otherwise the patch seems fine, if it tests OK, but I'm still a little > > > nervous about it. For example, you'll call val_print on a struct > > > or array to see if it's changed. Depending on things like "set print > > > elements", that might not print out the whole string. This is > > > probably a behavior change. Is it a harmless one? If it is, then > > > should we be sharing the code with c_value_of_variable that avoids > > > printing structs, unions, and arrays, and never mark them as changed > > > unless their types change? > > > > The function val_print is already used for -var-evaluate-expression. > > Not in the case I was talking about. -var-evaluate-expression calls > varobj_get_value, which calls c_value_of_variable, and will return > "{...}" for a struct. Won't it? > > > AFAICS "set print elements" has no effect on variable objects, > > perhaps because val_print is only called on the leaves but I can see > > that using it might expose MI to the vagaries of CLI. Currently, > > however, string changes don't get reported at all, without the user > > changing configuration values. > > "set print elements" will affect the output of character pointers, but > that's not really what I'm worried about - you're now going to print > out most of an array or struct when comparing print_value. > > 1. Can always set print_value to what c_value_of_variable would return? > > 2. Currently I believe we will mark an array varobj as updated in > -var-update if any of its children change. We never mark array varobj as changed, I believe. array varobj is included in -var-update output only if the type of the array changes, IIRC. > I'm not sure if we'll do > that any more after your patch, e.g. if something beyond the limit of > "set print elements" changes. So, do you think any front end relies on > the parent being marked updated if any of its children are? Vlad, > any opinion? I think the code in question is never executed for structures or arrays -- only for "changeable" values. - Volodya