From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13833 invoked by alias); 19 Mar 2008 09:14:59 -0000 Received: (qmail 13825 invoked by uid 22791); 19 Mar 2008 09:14:59 -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 09:14:29 +0000 Received: from kahikatea.snap.net.nz (55.61.255.123.dynamic.snap.net.nz [123.255.61.55]) by viper.snap.net.nz (Postfix) with ESMTP id 816A23D9ECE; Wed, 19 Mar 2008 22:14:21 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id F3AFA8FC6D; Wed, 19 Mar 2008 21:14:19 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18400.55659.354715.462161@kahikatea.snap.net.nz> Date: Wed, 19 Mar 2008 10:02:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec In-Reply-To: References: <200803190016.02072.vladimir@codesourcery.com> <18400.32557.752481.709565@kahikatea.snap.net.nz> 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/msg00151.txt.bz2 > > It's not a prompt, just a delimiter. For a start it has a newline after > > it. Furthermore if you change the prompt with "set prompt", it doesn't > > change. > > Let's call (gdb) a "MI prompt", then. Given that each MI output is already > terminated with a newline, (gdb) is not necessary to property parse MI > output. Then, the question is that does (gdb) mean? 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. > 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. > > > Each MI command results in either ^done, ^error, ^connected or ^running > > > response. The ^connected response is basically identical to ^done, > > > and the naming is different for historic reasons. All of those > > > except for ^running are immediately followed by prompt. The ^running > > > response means that the target has started running. Further events > > > from the target will be reported using async notifications. > > > > > > The async notifications are for various interesting events that cannot > > > generally be reported as result of a command. For example, > > > > > > =thread-created > > > > This notification doesn't appear to be in the manual. > > Because I'm still working for a doc patch for same. According to the syntax, as above, this should be: =thread-created,id="3" (gdb) > > Why are there no > > equivalent =thread-exited notifications? > > Because it's not implemented. Does that mean that you think that =thread-created is more useful? > Note that current thread.c implementation will only declare a thread as done > when we do -thread-info (or anything else that calls prune_threads, so the > value of =thread-exited will be limited, without some associated work on > threads layer). I'm not sure what you mean. If I run Gdb normally with a multi-threaded application, I get: [New Thread -1210639472 (LWP 7235)] when a thread is created and: [Thread -1210639472 (LWP 7235) exited] when it is terminated. > > > Presently, MI spec says a command can output ^running just once. > > > However, it the presense of breakpoint commands, it's quite possible > > > that we resume one thread, hit a breakpoint, and breakpoint commands > > > resume all threads, or some other thread. > > > > > > To handle this case we need a new async output for this case: > > > > > > *running,thread-id="xxx" > > > > ^running,thread-id="xxx" ? ("running" isn't an out-of-bound record) > > "*running" is the new async output proposed by this spec (and async-output > is a kind of out-of-bound record). We cannot use ^running, because ^running > is emitted once for each command, and each command can resume the target > several times, and possibly - different threads. Breakpoint command lists don't currently work in MI, 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. It probably doesn't matter that much if you use "*running" or "^running" and you can probably define asynchronous in different ways but I think starting execution and detecting stopped execution different in this respect. -- Nick http://www.inet.net.nz/~nickrob