From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23975 invoked by alias); 30 Oct 2003 19:40:03 -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 23964 invoked from network); 30 Oct 2003 19:40:02 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 30 Oct 2003 19:40:02 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5F0722B89; Thu, 30 Oct 2003 14:40:00 -0500 (EST) Message-ID: <3FA16910.5060902@redhat.com> Date: Thu, 30 Oct 2003 19:40:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii , Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Multiple locations vs. watchpoints. References: <20031030055345.GA7588@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00335.txt.bz2 > 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. Yes, it also applies to OO languages. The current SAL, frame, ... specify the scope that is used to qualify the breakpoint / watchpoint. >> 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. I think there are two largely independant problems here: - two level breakpoint / location table this assumes that something like "rbreak " just creates multiple breakpoints (which are then broken down into locations) - CLI operations and changes that provide greater flexability in manipulating the breakpoint table (rdelete, renable, breakpoint groups, ...?) and personally I'd be completly ignoring the second one for the moment. enjoy, Andrew