From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13439 invoked by alias); 29 May 2008 10:07:35 -0000 Received: (qmail 13430 invoked by uid 22791); 29 May 2008 10:07:35 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 May 2008 10:07:04 +0000 Received: from kahikatea.snap.net.nz (201.31.255.123.static.snap.net.nz [123.255.31.201]) by viper.snap.net.nz (Postfix) with ESMTP id 7086B3DA2FB; Thu, 29 May 2008 22:07:01 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 90EB98FC6D; Thu, 29 May 2008 22:06:57 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18494.32829.19820.247605@kahikatea.snap.net.nz> Date: Thu, 29 May 2008 16:46:00 -0000 To: Vladimir Prus Cc: gdb-patches@sourceware.org Subject: Re: Changes to varobj.c In-Reply-To: <200805291154.23776.vladimir@codesourcery.com> References: <18493.58735.890650.879225@kahikatea.snap.net.nz> <200805291154.23776.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.2.50.2 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: 2008-05/txt/msg00752.txt.bz2 > I think you've missed it. The patch was posted here: > > http://article.gmane.org/gmane.comp.gdb.patches/40822 > > and the version I've checked in has no changes relative to the one > I've posted. It looks like it was attached in reply to a patch with the subject header "[RFC][patch 0/9] Python support in GDB". I don't read everything posted to gdb-patches and delete messages based on the subject which is why I must have missed this one. > Would you like to CC-d on all MI patches? If you just give an indication in the subject header about the content, as you have suggested, that should be enough - thanks. > > I can see a stale comment before varobj_update: > > > > NOTE: This function may delete the caller's varobj. If it > > returns TYPE_CHANGED,... > > > > (varobj_update no longer returns TYPE_CHANGED) > > You are right. On the other hand, why do delete varobj when its type > changes, or in other words, why value_of_root uses varobj_create? I think > I'll just stop it making do so, If floating varobjs are used then var->root->exp changes when the frame changes and using varobj_create is one way to get hold of this expression. I think if you don't use varobj_create then you will have to use a chunk of it. > together with the other planned change of > making -var-create of floating varobj not fail when the expression cannot be > parsed. That's an independent matter though, right? -- Nick http://www.inet.net.nz/~nickrob PS I've just noticed that: struct varobj **cv; struct varobj **templist = NULL; are no longer used in varobj_update. I've updated my linked list patch to your changes and it looks cleaner. Using a vector for result seems like a good idea, I just don't think it works for varobj_list_children.