From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26883 invoked by alias); 21 Dec 2006 08:34:53 -0000 Received: (qmail 26875 invoked by uid 22791); 21 Dec 2006 08:34:53 -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 Dec 2006 08:34:46 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-15.snap.net.nz [202.124.125.15]) by viper.snap.net.nz (Postfix) with ESMTP id 06C2A3D8414; Thu, 21 Dec 2006 21:36:17 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 48F73BE3D3; Thu, 21 Dec 2006 21:30:08 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17802.17932.377094.90049@kahikatea.snap.net.nz> Date: Thu, 21 Dec 2006 08:34:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: variable objects and registers In-Reply-To: <200612210942.54734.ghost@cs.msu.su> References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <17801.40268.835284.224413@kahikatea.snap.net.nz> <200612210942.54734.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.0.92.1 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: 2006-12/txt/msg00284.txt.bz2 > > > I've settled on -var-list. I don't think 'create' clarifies much, > > > and this is not user command, > > > > Except that it doesn't just list existing variable objects but "creates" > > new ones. > > I fact, I'm not sure what duplicated > > -var-list --locals > > should do. Create afresh, or just return already created? Thats a fair point. It should only create new variable objects if execution enters a new block. That makes -var-list a reasonable name. In the manual I should have said "...creates variable objects for the children if they do not already exist.". > > The latter is "-stack-list-locals --make-varobjs" isn't it? Or are you > > talking about variables declared within compound statements? > > Both. -stack-list-locals --make-varobjs creates variable objects for all > variables in a function, including in nested blocks. Well plain "-stack-list-locals just prints those that are in scope (as does "info locals"). How does it differentiate between variable object for expressions with the same name? (ISTR varobj.c hashes the name of the expression to work out where to store it). > I think it might be good idea for you and I to go though Apple branch > grepping for all "APPLE LOCAL" markers so that we know everything they've > added. Apple have made extensive changes. I might look for specific changes if I'm pointed towards them (as for the asynchronous event loop) but I'm not going to look at all of it. > > The distinction I'm making is that var_* functions and variables are for > > use in MI and generally live in mi_cmd_var.c while varobj_* ones may be > > used by Insight and live in varobj.c > > I don't think the difference between "var" and "varobj" in function name > communicates what you want, and I don't think such a coding guideline makes > sense for future. Looking more closely the distinction doesn't seem to exist for variable names which are often just var for struct varobj (presumably for brevity). As long as there are two separate files for variable objects (because Insight only needs one, varobj.c), it seems a harmless and mildly useful guideline for function names to me. -- Nick http://www.inet.net.nz/~nickrob