From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24635 invoked by alias); 4 Jan 2007 20:50:56 -0000 Received: (qmail 24627 invoked by uid 22791); 4 Jan 2007 20:50:56 -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; Thu, 04 Jan 2007 20:50:48 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H2ZXr-0007Fd-P5; Thu, 04 Jan 2007 15:50:39 -0500 Date: Thu, 04 Jan 2007 20:50:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: RFC: MI - Detecting change of string contents with variable objects Message-ID: <20070104205039.GH24634@nevyn.them.org> Mail-Followup-To: Nick Roberts , Vladimir Prus , gdb-patches@sources.redhat.com References: <17798.19683.251190.740216@kahikatea.snap.net.nz> <200612181136.02429.ghost@cs.msu.su> <20061218133827.GA24800@nevyn.them.org> <17799.3497.476593.138858@kahikatea.snap.net.nz> <20070103224605.GO17935@nevyn.them.org> <17820.32496.851404.587153@kahikatea.snap.net.nz> <20070104042038.GA3918@nevyn.them.org> <17820.39505.966623.305338@kahikatea.snap.net.nz> <20070104194033.GB24634@nevyn.them.org> <17821.25837.573239.858406@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17821.25837.573239.858406@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: 2007-01/txt/msg00140.txt.bz2 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. 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? -- Daniel Jacobowitz CodeSourcery