From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2751 invoked by alias); 3 Apr 2008 11:28:16 -0000 Received: (qmail 2742 invoked by uid 22791); 3 Apr 2008 11:28:16 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 11:27:58 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1JhNbj-0004dT-Ji for gdb-patches@sources.redhat.com; Thu, 03 Apr 2008 15:27:54 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JhNba-0004dA-WE; Thu, 03 Apr 2008 15:27:43 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: [PATCH, gdb6.8] -break-list doesn't list multiple breakpoints Date: Thu, 03 Apr 2008 11:39:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47F3946A.3090000@op.pl> <18420.47850.169206.141581@kahikatea.snap.net.nz> In-Reply-To: <18420.47850.169206.141581@kahikatea.snap.net.nz> Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804031527.41839.ghost@cs.msu.su> 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: 2008-04/txt/msg00063.txt.bz2 On Thursday 03 April 2008 15:09:30 you wrote: > > > If set individually, the multiple breakpoint locations can be used with > > > deleted, ignore, condition and commands. > > > > To set individual breakpoint on constructor instances, for example, > > you need to set breakpoint at address. > > > > > Why would this not true when the > > > location is part of a multiple breakpoint? Is it just due to the > > > implementation or a fundamental limitation? > > > > That's the design of multiple-location breakpoints. You specify the line > > or function on which such a breakpoint should be set. GDB that arranges > > for the list of locations to automatically include all relevant addresses, > > including when shared libraries are loaded and unloaded. Note that while > > there's mechanism to enable and disable individual locations, it's a bit > > heuristic, so the enable/disable state might not be carried over when > > new shared libraries are loaded. > > > > Allowing the user to manipulate individual locations will interfere with > > this automatic updating of location list. > > I'm not familar with the need to load and unload shared libraries, Gdb just > loads them automatically for me. And while it loads them automatically, it also updates breakpoints. In particular new locations may be added to a breakpoint. Was this not clear from what I wrote above? > > > Furthermore, what is the use case? > > For constructors, one is not likely to ever want to do anything with > > individual locations. For inlined functions, I don't know why you would > > specifically treat one inlined instance, but if you wish, you can always > > create a more specific breakpoint, like on address, and do anything. > > > > Of course, we can provide a command that creates individual breakpoints on > > each address matching a specification, and does not do any auto-update of > > those breakpoints. If you think such a behaviour will be useful, can you > > explain why, and then work on implementing it? > > I can imagine it might be useful to control the breakpoint locations > individually but, in practice I've never needed multiple breakpoints yet. > However, if it's not useful then it's probably unlikely that anyone would > try to do it in a frontend as you suggested earlier: > > > Yes, but those are not a breakpoints, do it will do a disservice to the > existing frontends. In particular, might find it very interesting > experience to edit condition of one breakpoint, and having conditions on > other breakpoints change. Likewise, changing any properly of location will > not work. So, you suggest that frontend should display a number of fields for breakpoint locations in the hope that the user will never touch those fields? This will just clutter the UI. - Volodya