From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26426 invoked by alias); 30 Oct 2003 19:44:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26412 invoked from network); 30 Oct 2003 19:44:12 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 30 Oct 2003 19:44:12 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AFIiJ-0000kg-Nv; Thu, 30 Oct 2003 14:44:11 -0500 Date: Thu, 30 Oct 2003 19:44:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Multiple locations vs. watchpoints. Message-ID: <20031030194411.GA2786@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20031030055345.GA7588@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00336.txt.bz2 On Thu, Oct 30, 2003 at 08:21:44AM +0200, Eli Zaretskii wrote: > > Date: Thu, 30 Oct 2003 00:53:45 -0500 > > From: Daniel Jacobowitz > > > > Suppose we have this: > > foo.c:static int *bar; > > > > (gdb) watch *bar > > > > My idea has sort of been to create a watchpoint with multiple locations, one > > for bar and one for *bar, each representing a conceptual hardware watchpoint > > (though not necessarily one hardware watchpoint resource). > > Yes, we do it now, albeit differently at the high level. > > > And for this: > > foo.c:static int foo() > > bar.c:static int foo() > > > > (gdb) break foo > > > > My idea has sort of been that we should have a breakpoint with two > > bp_locations, one for foo.c:foo and one for bar.c:foo. > > I don't think we should do that. I think we should leave things as > they are now, namely, that "break foo" means the function foo in the > _current_ module, be that foo.c or bar.c. For the other, the user is > required to type "break bar.c:foo". > > In C++ and other OO languages, this is different, but in C we > shouldn't introduce confusion, IMHO. Someone who debugs a C program > doesn't expect to get a breakpoint on a completely different function. And when neither of these functions is in the "current" file (I hate transparent state like that)? We tend to get one at random. This kills me once in a while when working on BFD. > > But suppose we have this: > > foo.c:static int *bar; > > bar.c:static int *bar; > > > > (gdb) watch *bar > > > > > > It watches whatever *bar would print, which is one of them. No easy way to > > get at the other or describe the ambiguity. I wonder once again whether the > > two-level scheme is really correctly designed; but I have no better ideas. > > Accept my position about static functions in C, and this problem goes > away. > > But if you still want to put a watchpoint on both static variables, > then there might be no reason for multi-level schemes: simply have the > chain of addresses include foo.c:bar, foo.c:*bar, bar.c:bar, and > bar.c:*bar. > > Does this make sense? Yes, I think so. Hmm. This suggests that I may be overloading one data structure for two incompatible purposes. I need to think about it a little. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer