From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9272 invoked by alias); 22 Oct 2002 01:40:58 -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 9111 invoked from network); 22 Oct 2002 01:40:57 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 Oct 2002 01:40:57 -0000 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 69741800084; Mon, 21 Oct 2002 21:40:57 -0400 (EDT) Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7C0F13E13; Mon, 21 Oct 2002 21:40:56 -0400 (EDT) Message-ID: <3DB4ACA8.9080106@redhat.com> Date: Mon, 21 Oct 2002 18:40:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Seitz Cc: "J. Johnston" , gdb-patches@sources.redhat.com, alain@qnx.com Subject: Re: Patch for gdb/mi problem 702 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00378.txt.bz2 > 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? Andrew