From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8762 invoked by alias); 30 Nov 2007 05:52:19 -0000 Received: (qmail 8750 invoked by uid 22791); 30 Nov 2007 05:52:18 -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; Fri, 30 Nov 2007 05:52:13 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1IxynE-0004NQ-7I for gdb-patches@sources.redhat.com; Fri, 30 Nov 2007 08:52:09 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Ixyn4-0004NC-DF; Fri, 30 Nov 2007 08:51:54 +0300 From: Vladimir Prus To: Michael Snyder Subject: Re: Variable identification (Was: [RFA] Don't reset watchpoint block on solib load.) Date: Fri, 30 Nov 2007 05:52:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <200711202013.47537.vladimir@codesourcery.com> <1196384986.2501.141.camel@localhost.localdomain> In-Reply-To: <1196384986.2501.141.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711300851.51205.ghost@cs.msu.su> 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: 2007-11/txt/msg00559.txt.bz2 On Friday 30 November 2007 04:09:46 Michael Snyder wrote: > On Thu, 2007-11-29 at 22:02 +0300, Vladimir Prus wrote: > > Jim Blandy wrote: > > >> This is probably good behaviour, indeed. Or maybe we should not > > >> disable watchpoint, but mark it as pending, in the same sense of > > >> "user wanted it to be enabled, but it won't trigger until a shared > > >> lib is loaded" that is used for ordinary watchpoints. > > > > > > I think so, too. I guess the key observation is that, while it's not > > > meaningful to talk about a particular local variable "coming back > > > alive", since each function call creates a distinct set of local > > > variables, and you can have recursion, etc., it is meaningful to talk > > > about a shared library being reloaded, and it's intuitive to identify > > > the 'X' from the first loading with the 'X' in the second loading, > > > even if they're at different addresses. > > > > Yes. I now recall this is more general problem with identification of > > variables in GDB. Say, you're in function, and you have local variable > > 'foo'. In GUI, you do something with 'foo' -- set display format to > > hex, expand it, and so on. It's highly desirable to keep this > > information for the next run of program, or even next run of the GUI -- > > even if variable is local, it's not likely that the display properties > > user wants depend on frame. > > > > Unfortunately, there's no way to do that. > > I haven't followed the discussion closely, but > shouldn't it be up to the GUI to keep such persistant > info? It's nothing to do with gdb, really. It's the > GUI's state. It's GUI state, true. But to keep it, GUI needs some identifier for variables, that is is persistent across program restarts, preferably even if program changes. Presently, there's no such identifier provided by GDB. - Volodya