From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9317 invoked by alias); 20 Jan 2008 11:09:16 -0000 Received: (qmail 9308 invoked by uid 22791); 20 Jan 2008 11:09: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; Sun, 20 Jan 2008 11:08:57 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1JGY2h-00026u-Qj for gdb-patches@sources.redhat.com; Sun, 20 Jan 2008 14:08:52 +0300 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_SHA:32) (Exim 4.50) id 1JGY2Z-00026i-3s; Sun, 20 Jan 2008 14:08:39 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: [PATCH] Re: bug in mi when setting breakpoint Date: Sun, 20 Jan 2008 11:09:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <20071216125625.GE4783@coin> <200801201307.44269.ghost@cs.msu.su> <18323.9357.162234.395545@kahikatea.snap.net.nz> In-Reply-To: <18323.9357.162234.395545@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801201408.41661.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-01/txt/msg00496.txt.bz2 On Sunday 20 January 2008 13:38:05 Nick Roberts wrote: > > 3. Assuming we have a list of breakpoints (which Eclipse and KDevelop > > do), we surely can delete breakpoints there. However, adding unwanted > > breakpoints right away will not be good in non-stop mode: > > > > - Some threads might already stop on unwanted breakpoints before you > > delete them > > - You might run out of hardware resources while setting unwanted > > breakpoints > > Running GDB in "non-stop mode" sounds highly ambitious and may happen a long > time in the future, if at all. I'm not sure if you saw an announcement about non-stop mode project. It's rather near future. > I'm talking about implementing a simple > solution, for now. Even if non-stop mode does become a reality, it presumably > won't be the default behaviour, so it won't break existing front ends. This does not mean that all MI commands should behave differently in non-stop mode. > > I think it's more clear to set only those breakpoints that user want to set, > > as opposed to setting all of them, and then removing undesired ones. > > Yes, but I still haven't see how you propose to do this. -break-insert, in case when there are several overloaded functions, should return this: ^error,msg="Several overloaded functions found", functions=["int f(int)", "int f(double)"] then, break-insert should have an -o parameter that specifies a list of overloaded functions to set breakpoints on: -break-insert -o 0 f - Volodya