From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17889 invoked by alias); 18 Jul 2004 21:49:45 -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 17876 invoked from network); 18 Jul 2004 21:49:44 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 18 Jul 2004 21:49:44 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BmJWf-0007yZ-BQ; Sun, 18 Jul 2004 17:48:53 -0400 Date: Mon, 19 Jul 2004 03:22:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: mec.gnu@mindspring.com, gdb@sources.redhat.com, rolandz@poczta.fm Subject: Re: How to setup a breakpoint on constructor Message-ID: <20040718214852.GA30558@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , mec.gnu@mindspring.com, gdb@sources.redhat.com, rolandz@poczta.fm References: <20040717205225.56BC04B104@berman.michael-chastain.com> <9003-Sun18Jul2004071107+0300-eliz@gnu.org> <20040718050420.GA13745@nevyn.them.org> <9003-Sun18Jul2004214239+0300-eliz@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9003-Sun18Jul2004214239+0300-eliz@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-07/txt/msg00238.txt.bz2 On Sun, Jul 18, 2004 at 09:42:39PM +0200, Eli Zaretskii wrote: > > Date: Sun, 18 Jul 2004 01:04:20 -0400 > > From: Daniel Jacobowitz > > > > > > Can't we put a breakpoint on all instances in that case as well? > > > > Yes. But this requires a certain amount of user interface design and > > implementation hackery that no one has done > > Sorry, I must be missing something: if we put the breakpoint on all > the instances of the constructor's code, and do that without asking > the user anything, what UI aspects need to be figured out and > designed? Is it one breakpoint with multiple addresses, or have we created multiple breakpoints? If the former, we have to somehow arrange to display them. If the latter, we have to somehow distinguish the two of them in the UI so that the user can see which is which; and generate different location strings for them, so that if the user recompiles and reloads the breakpoints get set on the same place, in case they have different conditions or commands or enable status. The general case of 'break ' has many similar issues, for instance in templates or inlined functions; describing the location is quite a problem. Not an insoluble one, surely, but I get stuck every time I work on it... -- Daniel Jacobowitz