From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18756 invoked by alias); 17 Jan 2007 21:34:20 -0000 Received: (qmail 18746 invoked by uid 22791); 17 Jan 2007 21:34:19 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Jan 2007 21:34:13 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H7IQ1-00068x-BN for gdb@sources.redhat.com; Thu, 18 Jan 2007 00:34:10 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1H7IPq-00068i-CH; Thu, 18 Jan 2007 00:33:54 +0300 From: Vladimir Prus Subject: Re: -var-list --locals proposal To: Nick Roberts , gdb@sources.redhat.com Date: Wed, 17 Jan 2007 21:34:00 -0000 References: <200701052303.59465.ghost@cs.msu.su> <17837.54839.540250.189975@kahikatea.snap.net.nz> User-Agent: KNode/0.10.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: 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/msg00276.txt.bz2 Nick Roberts wrote: > > > 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. I don't think so. If there's a way in gdb to say "varobj really gone out of scope", and the frontend does not delete varobj infinitely after getting such information, it's a bug in a frontend. > 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. Okay. Note that this optimization is actually optional. The way I've specified -var-list, it is not required to cache varobjs, it's allowed to. > > > 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. Having two varobjs for a local is fine. The reason I don't want to create varobjs when not necessary is that given that variable name is not enough, varobj name is the only way for frontend to identify a variable. If -var-list --locals returned varobj1 last time and now report varobj2, the frontend should assume it's completely new variable, delete UI item and create new. The old new item might be expanded by user, deleting/creating kills that. > > > > 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. Doh, I meant: Arguments are also shown in the stack window. - Volodya