From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5767 invoked by alias); 1 Dec 2007 01:39:53 -0000 Received: (qmail 5748 invoked by uid 22791); 1 Dec 2007 01:39:52 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Dec 2007 01:38:32 +0000 Received: (qmail 4995 invoked from network); 1 Dec 2007 01:38:30 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Dec 2007 01:38:30 -0000 To: Michael Snyder Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: Variable identification References: <200711202013.47537.vladimir@codesourcery.com> <1196384986.2501.141.camel@localhost.localdomain> From: Jim Blandy Date: Sat, 01 Dec 2007 01:39:00 -0000 In-Reply-To: <1196384986.2501.141.camel@localhost.localdomain> (Michael Snyder's message of "Thu, 29 Nov 2007 17:09:46 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00001.txt.bz2 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.