From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12177 invoked by alias); 29 Nov 2007 19:03:59 -0000 Received: (qmail 12166 invoked by uid 22791); 29 Nov 2007 19:03:58 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 Nov 2007 19:03:49 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxofA-0006FQ-MC for gdb-patches@sources.redhat.com; Thu, 29 Nov 2007 19:03:34 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 19:03:04 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 19:03:04 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Variable identification (Was: [RFA] Don't reset watchpoint block on solib load.) Date: Thu, 29 Nov 2007 19:03:00 -0000 Message-ID: References: <200711202013.47537.vladimir@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 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/msg00553.txt.bz2 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. - Volodya