From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27443 invoked by alias); 28 Nov 2007 22:18:36 -0000 Received: (qmail 27434 invoked by uid 22791); 28 Nov 2007 22:18:35 -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:18:31 +0000 Received: (qmail 28104 invoked from network); 28 Nov 2007 22:18:29 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Nov 2007 22:18:29 -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> From: Jim Blandy Date: Wed, 28 Nov 2007 22:18:00 -0000 In-Reply-To: <200711281858.51145.vladimir@codesourcery.com> (Vladimir Prus's message of "Wed, 28 Nov 2007 18:58:50 +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/msg00531.txt.bz2 Actually, let me withdraw the three steps I suggested above. I understand that I'm straying from commenting on your patch --- apologies --- but that's because as I tried to think about it, I became confused about what behavior we actually want to get out of GDB. Here's the behavior I think we actually want: A watchpoint should 'stick' to the scope it was originally set in. For example, suppose I have a shared library libx.so with a source file x.c, and that x.c has a static variable S. And suppose there's also a global variable named S defined in the main program. While control is stopped somewhere in x.c, I set a watchpoint on S. Clearly, that watchpoint refers to x.c's static S, not the global S. Now, if I later unload libx.so, the watchpoint should delete itself with an appropriate message, just as a watchpoint on a stack variable does when its frame is popped --- when a shared library is unloaded, that ends the lifetimes of the variables it defines, just as exiting a block ends the lifetimes of the variables defined in the block. But specifically, the watchpoint should *not* transform into a watchpoint on the global S. That's an entirely different variable; it could even have a different type. This is what I mean by a watchpoint 'sticking' to the scope it was set in. So, opening and closing shared libraries should never cause us to re-parse a watchpoint's expression. Loading a shared library should never re-parse a watchpoint expression, because the watchpoint should stick to its original scope, which is still there. Unloading a shared library should never re-parse the watchpoint expression, but it should delete the watchpoint if it refers to variables from shared library, since they're gone now. This isn't what GDB does now, but I think this behavior is not hard to obtain. When we set a watchpoint, instead of b->exp_valid_block, we should record the PC in whose scope we parsed the expression. When we check a watchpoint's condition, we should look up the PC's block: if we can't find one, then we've unloaded symbolic information for that watchpoint, and we should delete it. The tricky part is deciding what to do when the main executable file is modified. It's hard to see what exactly the watchpoint should stick to in this case, since the PC isn't a reliable identifier across such changes. Perhaps it would be enough to also record the name of the function and source file the PC falls in, re-parse if they have remained stable, and delete the watchpoint if they have changed.