From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22474 invoked by alias); 4 Oct 2002 16:57:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22447 invoked from network); 4 Oct 2002 16:57:05 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 4 Oct 2002 16:57:05 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id EC18A8000E6; Fri, 4 Oct 2002 12:57:04 -0400 (EDT) Message-ID: <3D9DC860.ED55D3F5@redhat.com> Date: Fri, 04 Oct 2002 09:57:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. X-Accept-Language: en MIME-Version: 1.0 To: Keith Seitz Cc: gdb-patches@sources.redhat.com, alain@qnx.com Subject: Re: Patch for gdb/mi problem 702 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00129.txt.bz2 Keith Seitz wrote: > > On Thu, 3 Oct 2002, J. Johnston wrote: > > > The following fixes a problem with -var-assign whereby an assignment > > of a new value is not seen by a subsequent -var-update. The > > underlying varobj_update call looks to see if there is a difference > > between the current value and a refreshed value. Since varobj_set_value > > actually changes both the internal value and the actual value, varobj_update > > does not add the variable to the changelist. > > The real question is: is it really necessary for an assignment to show up > in the udpate list. IMO, it doesn't matter, because the caller will know if > the assignment succeeded or failed. If it failed, it'll have an error > message from MI. Otherwise, it knows that it worked and all it needs to do > is fetch the value of this variable (to get the right display format) and > update the displayed value on the screen. There's no reason to do an > update, which is not a cheap operation. > > I really don't know what to make of this. I don't think this is really > necessary. It seems like a substitute for error checking. > > Perhaps Alain can comment on why this is necessary with Eclipse? > > Keith Consider the following scenario. An application has output windows showing a number of variables. Some of these output variables are aliases of one another (e.g. *p which points to a[5] which is also being shown). The application kicks off a separate input field operation that changes the value of a[5]. Now, the application knows it changed a[5], but doesn't necessarily know about the current alias to *p. With patch, if the -var-update is performed after the -var-assign, both values will show that they need update. Without the patch, only the *p value will show up (the original assignment won't). Arguably, the application could track this, but it seems to make sense to keep it clean. The "change value" window could simply signal that a value has changed and let any corresponding windows issue their own updates. -- Jeff J.