From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31391 invoked by alias); 19 Mar 2008 12:01:11 -0000 Received: (qmail 31382 invoked by uid 22791); 19 Mar 2008 12:01:11 -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; Wed, 19 Mar 2008 12:00:40 +0000 Received: from kahikatea.snap.net.nz (120.63.255.123.dynamic.snap.net.nz [123.255.63.120]) by viper.snap.net.nz (Postfix) with ESMTP id 9FEE23DA970; Thu, 20 Mar 2008 01:00:32 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id A0BF18FC6D; Thu, 20 Mar 2008 00:00:30 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18401.93.772177.582238@kahikatea.snap.net.nz> Date: Wed, 19 Mar 2008 12:30:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec In-Reply-To: <200803191301.38063.vladimir@codesourcery.com> References: <200803190016.02072.vladimir@codesourcery.com> <18400.55659.354715.462161@kahikatea.snap.net.nz> <200803191301.38063.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.1.92.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00156.txt.bz2 > > Well I've not tried to parse the MI output on it's own, in earnest, yet > > but if it's a delimiter then means that the parser can find the end of the > > output record. > > And what's the practical value? Both KDevelop and CDT parse MI output > line-by-line, and it appears to be just enough. Maybe you're right but the "(gdb) \n" doesn't seem to cost much. > > > If it does not mean > > > anything, it should be, ideally, just removed. And if it means anything, > > > then what? Current behaviour is not consistent, but the code suggests > > > that it's meant to indicate when GDB is ready for a new command. I think > > > such a behaviour will be useful for a frontend. > > > > If it stays, the frontend can just use the rule that GDB is ready for a new > > command after "(gdb)\n" unless it's preceded by ^running. > > Which happens to be wrong. In async mode, gdb *may* be ready for a new > command even if ^running is output. And whether it's ready or not, generally > depends on the command In async mode Gdb is pretty much always ready for a new command isn't it? > > > >... > > Breakpoint command lists don't currently work in MI, > > Do you suggest they should never work? No, but breaking my sentence here might make it appear that I did. > They probably don't work because > nobody tried to make them -- we have a call to bpstat_do_actions in > mi_interpreter_exec_continuation so we try to do them only for CLI commands, > and only in async mode. CLI commands like "commands" that query the user don't fit well with MI. Apple have created an MI command called -break-commands which gets round this problem for "commands". > > so your scenario is a bit hypothetical, but if they did then it's quite > > possible that we hit a breakpoint on one thread and breakpoint commands > > resume all threads without async mode. > > Yes, and what's wrong about that? We still need to accurately report to > the frontend which threads are running, so that the frontend does not > allow the user to mess with the currently running threads. There's nothing "wrong" about that, just that apart from adding the thread id, I can't see much difference to the present case. -- Nick http://www.inet.net.nz/~nickrob