From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5959 invoked by alias); 19 Mar 2008 06:26:15 -0000 Received: (qmail 5950 invoked by uid 22791); 19 Mar 2008 06:26:14 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 06:25:55 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbrkB-0004Ul-9e for gdb@sources.redhat.com; Wed, 19 Mar 2008 06:25:47 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 06:25:47 +0000 Received: from vladimir by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 06:25:47 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI non-stop mode spec Date: Wed, 19 Mar 2008 09:14:00 -0000 Message-ID: References: <200803190016.02072.vladimir@codesourcery.com> <18400.32557.752481.709565@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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/msg00150.txt.bz2 Nick Roberts wrote: > > (*) 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. 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? 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. > > 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. > Why are there no > equivalent =thread-exited notifications? Because it's not implemented. 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). > >... > > 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. > > 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. Ok. I have not fundamental objections to add CLI commands, however each CLI command added must be individually examined and its behaviour in non-stop/async case should be clarified -- which is what I'm trying to do for MI. > >... > > - 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) It's everywhere. The problem is that current GDB does not agree with the obvious fact that a single-threaded program has a single thread. Instead, it believes such a program has zero threads. Above is just one example of the inconsistency. Dan has just posted an in-progress patch that causes ptid not to change (gaining non-zero tid member) when program goes from ST to MT, and I have a patch to early add ptid of the main thread to the thread table, so hopefully we'll have this sorted. - Volodya