From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19213 invoked by alias); 30 Nov 2007 01:22:50 -0000 Received: (qmail 19204 invoked by uid 22791); 30 Nov 2007 01:22:50 -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; Fri, 30 Nov 2007 01:22:46 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 3AF9F3C175; Thu, 29 Nov 2007 17:22:44 -0800 (PST) Subject: Re: Variable identification (Was: [RFA] Don't reset watchpoint block on solib load.) From: Michael Snyder To: Vladimir Prus Cc: gdb-patches@sources.redhat.com In-Reply-To: References: <200711202013.47537.vladimir@codesourcery.com> Content-Type: text/plain Date: Fri, 30 Nov 2007 01:22:00 -0000 Message-Id: <1196384986.2501.141.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-11/txt/msg00557.txt.bz2 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.