From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9262 invoked by alias); 1 Dec 2007 01:47:54 -0000 Received: (qmail 9253 invoked by uid 22791); 1 Dec 2007 01:47:53 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Dec 2007 01:47:47 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 1907D3BF8D; Fri, 30 Nov 2007 17:47:46 -0800 (PST) Subject: Re: Variable identification From: Michael Snyder To: Jim Blandy Cc: Vladimir Prus , gdb-patches@sources.redhat.com In-Reply-To: References: <200711202013.47537.vladimir@codesourcery.com> <1196384986.2501.141.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 01 Dec 2007 01:47:00 -0000 Message-Id: <1196472874.2501.187.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit 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: 2007-12/txt/msg00002.txt.bz2 On Fri, 2007-11-30 at 17:38 -0800, Jim Blandy wrote: > Michael Snyder writes: > > 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. > > These questions all affect how watchpoints behave in the CLI as well. Right, with the CLI being a special case of "the GUI" -- one in which we (gdb maintainers) have control of everything. GDB can keep track of the CLI "state", but other GUI should keep track of their own state.