From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32162 invoked by alias); 20 Jan 2008 20:32:58 -0000 Received: (qmail 32154 invoked by uid 22791); 20 Jan 2008 20:32:57 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 20 Jan 2008 20:32:32 +0000 Received: from kahikatea.snap.net.nz (12.31.255.123.static.snap.net.nz [123.255.31.12]) by viper.snap.net.nz (Postfix) with ESMTP id 27F1E3D9E58; Mon, 21 Jan 2008 09:32:25 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id A0B1C8FC6D; Mon, 21 Jan 2008 09:32:24 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18323.45014.340535.910232@kahikatea.snap.net.nz> Date: Sun, 20 Jan 2008 20:32:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Re: bug in mi when setting breakpoint In-Reply-To: <200801201408.41661.ghost@cs.msu.su> References: <20071216125625.GE4783@coin> <200801201307.44269.ghost@cs.msu.su> <18323.9357.162234.395545@kahikatea.snap.net.nz> <200801201408.41661.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 23.0.50.33 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-01/txt/msg00499.txt.bz2 > > 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. You probably know more than me, it didn't give any timescales. > > 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. They wouldn't. I don't see why we should design MI commands around a feature that doesn't exist yet and will presumably be optional. > > > 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)"] In Emacs, multiple breakpoints for overloaded functions would be specified from the GUD buffer. How do you specify them graphically? > then, break-insert should have an -o parameter that specifies a list of > overloaded functions to set breakpoints on: > > -break-insert -o 0 f It all seems rather elaborate, but I don't feel that strongly about it as I'm not yet in a position to fully migrate Emacs to GDB/MI. -- Nick http://www.inet.net.nz/~nickrob