From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19560 invoked by alias); 19 Mar 2008 12:30:53 -0000 Received: (qmail 19550 invoked by uid 22791); 19 Mar 2008 12:30:52 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 12:30:27 +0000 Received: (qmail 13610 invoked from network); 19 Mar 2008 12:30:25 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Mar 2008 12:30:25 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: MI non-stop mode spec Date: Wed, 19 Mar 2008 13:43:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sources.redhat.com References: <200803190016.02072.vladimir@codesourcery.com> <200803191301.38063.vladimir@codesourcery.com> <18401.93.772177.582238@kahikatea.snap.net.nz> In-Reply-To: <18401.93.772177.582238@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: <200803191530.24005.vladimir@codesourcery.com> 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/msg00157.txt.bz2 On Wednesday 19 March 2008 15:00:29 Nick Roberts wrote: > > > 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. It make it impossible to know if gdb is ready for input. > > > > 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? Not necessary. For example, presently calling of function in inferior is not async, and making it async is fairly complex. > > > > >... > > > 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. Well, I can set breakpoint commands in MI just fine, it's just they are not run. > Apple have created an MI command called -break-commands which gets round > this problem for "commands". Yes, it's not very hard to grab, in fact. > > > 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. Is it either: 1. You don't believe that a single command can result in more than one resumption, of different threads? 2. You think it's fine to emit ^running several times? - Volodya