From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14913 invoked by alias); 17 Jan 2007 07:54:53 -0000 Received: (qmail 14900 invoked by uid 22791); 17 Jan 2007 07:54:52 -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; Wed, 17 Jan 2007 07:54:44 +0000 Received: from kahikatea.snap.net.nz (unknown [123.255.62.204]) by viper.snap.net.nz (Postfix) with ESMTP id 372AA3D85BD; Wed, 17 Jan 2007 20:54:36 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 122574F711; Wed, 17 Jan 2007 20:54:32 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17837.54839.540250.189975@kahikatea.snap.net.nz> Date: Wed, 17 Jan 2007 07:54:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: -var-list --locals proposal In-Reply-To: References: <200701052303.59465.ghost@cs.msu.su> <17837.22296.701551.796666@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.0.92.10 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-01/txt/msg00266.txt.bz2 > > > So, you either have frame_id->list_of_varobjs mapping in gdb, or in > > > the frontend. I'm not sure which one is better. If this kept in a > > > frontend, you'd also need notification "frame id XXX has died" so that > > > the frontend can clean up its mapping. > > > > I think there should varobjs that are created from locals > > The above sentence looks grammatically incorrect. That's because it's not a sentence but part of one i.e a phrase, but I don't want to get smart because my Russian is non-existant. It's probably lazy English. I'm trying to say that while you appear to be talking about keeping track of varobjs across frames, for locals, I'm thinking of only keeping them for the current frame. > > which get > > deleted when leaving the frame, and ordinary varobjs (which I guess could > > get deleted > > if they aren't globals). > > I don't think gdb should be deleting any varobjs automatically. It's > easier to program things if all varobj deletion is done by the frontend. Well the variable doesn't exist anymore, and you're going to start accumulating varobjs. It might be easier to recreate them when needed than keep track of them. However, if you implement something, maybe I'll change my mind. > > Normally the user won't create two watch > > expressions > > for the same variable but I think that should be his business. I think it > > would be hard to avoid duplication as one watch expression might be a > > child object. > > Sorry, I don't quite understand. Can you clarify? I was always thinking that > "watches" (same as gdb CLI "display") would be implemented by creating > "selected frame" varobjs -- and those have nothing to do with -var-list. I'm just saying that it probably doesn't matter if there is more than one variable object created for a single expression. Maybe, though, that's because I'm not thinking of the varobjs for locals existing outside their frame. > > > We'd need similar thing for function arguments, perhaps -- command like > > > > > > -var-list --arguments > > > > In Insight arguments are listed alongside locals. It might be a good idea > > to have: > > > > -var-list --args-and-locals > > > > and perhaps a field to say which is which. It seems sensible to list them > > all in one window. > > Locals are also shown in the stack window. I've never seen them there in any debugger that I've used. -- Nick http://www.inet.net.nz/~nickrob