From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12237 invoked by alias); 21 Jun 2007 21:31:32 -0000 Received: (qmail 12224 invoked by uid 22791); 21 Jun 2007 21:31:28 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Jun 2007 21:31:25 +0000 Received: from kahikatea.snap.net.nz (191.63.255.123.dynamic.snap.net.nz [123.255.63.191]) by viper.snap.net.nz (Postfix) with ESMTP id 1ACCE3D984F; Fri, 22 Jun 2007 09:31:22 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id E5F5E8FBF6; Fri, 22 Jun 2007 09:31:20 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18042.60967.652281.816747@kahikatea.snap.net.nz> Date: Thu, 21 Jun 2007 21:31:00 -0000 To: Daniel Jacobowitz Cc: Srrr , gdb@sourceware.org Subject: Re: BUG: MI reporting wrong attributes for casted variables In-Reply-To: <20070621202555.GA30881@caradoc.them.org> References: <000001c7b427$5822d330$02b2a8c0@insanenotebook> <18042.56547.598273.973421@kahikatea.snap.net.nz> <20070621202555.GA30881@caradoc.them.org> X-Mailer: VM 7.19 under Emacs 22.1.50.4 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00181.txt.bz2 Daniel Jacobowitz writes: > On Fri, Jun 22, 2007 at 08:17:39AM +1200, Nick Roberts wrote: > > Report it as a bug to the Eclipse CDT team. They have misinterpreted the > > meaning of the "editable" attribute. > > > > This has been reported at leasted once before, possibly by you (or at least > > another Sascha using Eclipse CDT) when I said: > > And also by Vladimir, two years ago. What is the use of the current > "editable" attribute? I don't see anything in the manual that would > conflict with changing it. Actually looking at the manual, rather than the code, it looks like this might have been the intended meaning: The `-var-assign' Command ------------------------- Synopsis ........ -var-assign NAME EXPRESSION Assigns the value of EXPRESSION to the variable object specified by NAME. The object must be `editable'. If the variable's value is ^^^^^^^^ altered by the assign, the variable will show up in any subsequent `-var-update' list. So if you mean add this case to the existing ones, that seems reasonable. It would make redisplay faster if this field was added to the output of -var-create and -var-list-children. This is probably especially important for remote targets. Incidentally, I find it strange that GDB can assign values to constant types: const i21 = 5; -var-create - * i21 ^done,name="var1",numchild="0",value="5",type="const int" (gdb) -var-assign var1 9 ^done,value="9" (gdb) -- Nick http://www.inet.net.nz/~nickrob