From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8660 invoked by alias); 28 Nov 2007 22:37:07 -0000 Received: (qmail 8530 invoked by uid 22791); 28 Nov 2007 22:37:06 -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; Wed, 28 Nov 2007 22:37:00 +0000 Received: (qmail 28834 invoked from network); 28 Nov 2007 22:36:59 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Nov 2007 22:36:59 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't reset watchpoint block on solib load. References: <200711202013.47537.vladimir@codesourcery.com> <200711281858.51145.vladimir@codesourcery.com> <200711282304.16403.vladimir@codesourcery.com> From: Jim Blandy Date: Wed, 28 Nov 2007 22:37:00 -0000 In-Reply-To: <200711282304.16403.vladimir@codesourcery.com> (Vladimir Prus's message of "Wed, 28 Nov 2007 23:04:16 +0300") 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-11/txt/msg00533.txt.bz2 Vladimir Prus writes: >> The steps I wrote don't address the case of watchpoints that aren't >> frame-relative. I wonder how we should be dealing with those. >> >> If we have a watchpoint on a static variable local to some file or >> block, then I don't honestly see how we can possibly re-set it >> correctly after a symbol reload with the data we have now. We can't >> tell whether b->exp_valid_block is a dangling pointer or not, and >> b->watchpoint_frame will be null on such watchpoints. > > I haven't run into any case when b->exp_valid_block is not-NULL, > but b->watchpoint_frame is NULL. By 'dangling pointer', I mean that it's referring to a block that was freed when we freed the objfile it belongs to. My point was just that neither of those fields would be useful in addressing the problem I described. > In fact, we don't need to care about blocks for global watchpoints -- > just like ordinary breakpoint on 'foo' does not care which shared library > 'foo' comes from, global watchpoint on 'important_data_structure' need > not care about where that variable comes from. If we re-parse watchpoint > expression on each solib load, things are fine. Our messages crossed paths: I think we should worry about re-parsing global watchpoints in the proper scope. For example, we do take care to remember which function breakpoints refer to when there is more than one possible referent. In the transcript below, note that the breakpoint set on the static 'foo' in t2.c, as opposed to the global 'foo' in t1.c, remains there even when we re-read the main executable. Watchpoints should behave the same way. $ cat t1.c #include void bar (void); void foo (void) { puts ("t1.c: foo"); } int main (int argc, char **argv) { foo (); bar (); return 0; } $ cat t2.c #include static void foo (void) { puts ("t2.c: foo"); } void bar (void) { foo (); } $ gcc -g t1.c t2.c -o t $ ~/gdb/pub/bin/gdb t GNU gdb 6.7.50.20071127-cvs Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) break bar Breakpoint 1 at 0x80483de: file t2.c, line 13. (gdb) run Starting program: /home/jimb/play/t t1.c: foo Breakpoint 1, bar () at t2.c:13 13 foo (); (gdb) break foo Breakpoint 2 at 0x80483ca: file t2.c, line 6. (gdb) i br Num Type Disp Enb Address What 1 breakpoint keep y 0x080483de in bar at t2.c:13 breakpoint already hit 1 time 2 breakpoint keep y 0x080483ca in foo at t2.c:6 (gdb) c Continuing. Breakpoint 2, foo () at t2.c:6 6 puts ("t2.c: foo"); (gdb) shell touch t (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y `/home/jimb/play/t' has changed; re-reading symbols. Starting program: /home/jimb/play/t t1.c: foo Breakpoint 1, bar () at t2.c:13 13 foo (); (gdb) info break Num Type Disp Enb Address What 1 breakpoint keep y 0x080483de in bar at t2.c:13 breakpoint already hit 1 time 2 breakpoint keep y 0x080483ca in foo at t2.c:6 (gdb) c Continuing. Breakpoint 2, foo () at t2.c:6 6 puts ("t2.c: foo"); (gdb)