From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2347 invoked by alias); 19 Mar 2008 02:49:53 -0000 Received: (qmail 2334 invoked by uid 22791); 19 Mar 2008 02:49:52 -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 02:49:25 +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 E18F23DAA11; Wed, 19 Mar 2008 15:49:21 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 7AE108FC6D; Wed, 19 Mar 2008 14:49:19 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18400.32557.752481.709565@kahikatea.snap.net.nz> Date: Wed, 19 Mar 2008 06:26:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec In-Reply-To: <200803190016.02072.vladimir@codesourcery.com> References: <200803190016.02072.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 23.0.60.42 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/msg00149.txt.bz2 > (*) Current MI syntax says that any result record must be followed by a > prompt. For sync targets, this is wrong -- when gdb prints ^running > and resumes the target, it does not check for input, so (gdb) is misleading. > When the target stops, the *stopped message, followed by the prompt is > printed -- and it's at this point that gdb starts to accept the input > again. So, I propose to remove the prompt right after ^running for the > sync targets. 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. > 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. Why are there no equivalent =thread-exited notifications? >... > 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) > which is emitted whenever a previously stopped thread is resumed. > In case all threads are resumed, "xxx" will be "all". > To simplify things, if GDB is started in MI mode, no CLI command is allowed > while the target is running, and -interpreter-exec is not allowed either. If you can make this work with MI commands, it should be easy to add CLI commands to do the same thing. I will do this. >... > - Thread commands. The -thread-info command should be implemented (a > patch is already posted). Notice that there is currently an inconsistency here: -exec-run ^running (gdb) *stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",... ^^^^^^^^^^^^ while (gdb) -thread-info ^done,threads=[] (gdb) -thread-info 0 ^done,threads=[] (gdb) b main thread 0 &"b main thread 0\n" &"Unknown thread 0.\n" ^error,msg="Unknown thread 0." (gdb) -- Nick http://www.inet.net.nz/~nickrob