From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25437 invoked by alias); 16 Jan 2007 23:12:04 -0000 Received: (qmail 25428 invoked by uid 22791); 16 Jan 2007 23:12:04 -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; Tue, 16 Jan 2007 23:12:00 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H6xT6-0005yZ-QL for gdb@sources.redhat.com; Wed, 17 Jan 2007 02:11:57 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1H6xSx-0005yC-GD; Wed, 17 Jan 2007 02:11:44 +0300 From: Vladimir Prus Subject: Re: -var-list --locals proposal To: Nick Roberts , gdb@sources.redhat.com Date: Tue, 16 Jan 2007 23:12:00 -0000 References: <200701052303.59465.ghost@cs.msu.su> <17837.22296.701551.796666@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/msg00264.txt.bz2 Nick Roberts wrote: > > 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. > 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. > 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. > > 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. - Volodya