From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24515 invoked by alias); 22 Oct 2002 21:54:50 -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 24508 invoked from network); 22 Oct 2002 21:54:49 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 Oct 2002 21:54:49 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 5818280007A; Tue, 22 Oct 2002 17:54:49 -0400 (EDT) Message-ID: <3DB5C929.1C9D9137@redhat.com> Date: Tue, 22 Oct 2002 14:54:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney Cc: Keith Seitz , gdb-patches@sources.redhat.com, alain@qnx.com Subject: Re: Patch for gdb/mi problem 702 References: <3DB4ACA8.9080106@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00431.txt.bz2 Andrew Cagney 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? > > To play the devil's devil advocate ... > > Consider a memory mapped register with sticky bits (no I'm not just > making this up, I recently got asked this exact question - I've a vague > recollection of complaints about gdb's current behavior in this regard). > > I think ``the right thing'' is: > > - the expression evaluation writes the value all the way through to the > target > - gdb invalidates everything - memory and register caches, varobj > - gdb evaluates all variable objects including that just written value. > - -var-update lists all values that changed > > The result could even be that that the modified variable didn't change > because that modified variable is truely ``stuck'' or that some of the > modified value is restored. > > So what does the MI and the patch do in this case? > I think we are ok. The -var-update code calls value_of_root at the top to get a "new" value before comparing. This operation ends up calling gdb_evaluate_expression which should handle fetching the real value and any sticky bits should be set properly. The new code now looks at the "updated" flag which I added. If this flag is on, it puts the item on the list. This causes the current varobj value to be updated with value "new" so all should be fine. -- Jeff J. > Andrew