From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4736 invoked by alias); 3 Apr 2008 11:36:00 -0000 Received: (qmail 4724 invoked by uid 22791); 3 Apr 2008 11:35:59 -0000 X-Spam-Check-By: sourceware.org Received: from smtp3.poczta.onet.pl (HELO smtp3.poczta.onet.pl) (213.180.130.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 11:35:39 +0000 Received: from static-62-233-152-148.devs.futuro.pl ([62.233.152.148]:2690 "EHLO [10.0.0.62]" rhost-flags-OK-OK-OK-FAIL) by ps3.test.onet.pl with ESMTPSA id S184564233AbYDCLfgUH0tC (ORCPT ); Thu, 3 Apr 2008 13:35:36 +0200 Message-ID: <47F4C107.1020801@op.pl> Date: Thu, 03 Apr 2008 11:52:00 -0000 From: Bogdan Slusarczyk User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Nick Roberts CC: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [PATCH, gdb6.8] -break-list doesn't list multiple breakpoints References: <47F3946A.3090000@op.pl> <18420.41316.87382.142756@kahikatea.snap.net.nz> <18420.47850.169206.141581@kahikatea.snap.net.nz> In-Reply-To: <18420.47850.169206.141581@kahikatea.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-04/txt/msg00064.txt.bz2 > I can imagine it might be useful to control the breakpoint locations > individually but, in practice I've never needed multiple breakpoints yet. I need it. Problem is that specific applications loads the same binaries few times (see SystemC simulators), and multiple breakpoints are very useful. > 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. I did changes for -break-list because I have situation when I have to disable one of location, and I have to find such location. Location behaves in different way as regular breakpoint, so I think it's not good idea to mix this things. I treat locations rather as breakpoint properties than regular breakpoints, but it's only my own opinion. Regards, Bogdan