From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17103 invoked by alias); 19 Mar 2008 11:16:26 -0000 Received: (qmail 17094 invoked by uid 22791); 19 Mar 2008 11:16:25 -0000 X-Spam-Check-By: sourceware.org Received: from vms042pub.verizon.net (HELO vms042pub.verizon.net) (206.46.252.42) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 11:16:02 +0000 Received: from black ([71.245.67.80]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JXZ00I3X5XZ9FW2@vms042.mailsrvcs.net> for gdb@sources.redhat.com; Wed, 19 Mar 2008 06:15:35 -0500 (CDT) Received: from bob by black with local (Exim 4.67) (envelope-from ) id 1JbwGc-0003Tt-KU; Wed, 19 Mar 2008 07:15:34 -0400 Date: Wed, 19 Mar 2008 11:20:00 -0000 From: Bob Rossi Subject: Re: MI non-stop mode spec In-reply-to: To: Vladimir Prus Cc: gdb@sources.redhat.com Mail-followup-to: Vladimir Prus , gdb@sources.redhat.com Message-id: <20080319111534.GG12641@brasko.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <200803190016.02072.vladimir@codesourcery.com> <18400.32557.752481.709565@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) 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/msg00154.txt.bz2 On Wed, Mar 19, 2008 at 09:25:39AM +0300, Vladimir Prus wrote: > 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. Exactly, "(gdb)" means nothing except, output ==> ( out-of-band-record )* [ result-record ] "(gdb)" nl exactly that. It is the end of the output record. I can tell you that my parser can probably handle not having (gdb) in it, because the "(gdb)" isn't the end symbol, the newline is. In fact, look at my grammar here, output: opt_oob_record_list opt_result_record OPEN_PAREN variable CLOSED_PAREN NEWLINE { You can see that I could probably remove the OPEN_PAREN variable CLOSED_PAREN part, and simply look for the NEWLINE. In fact, if I remove them, I do not get an error from bison. So, yes, it is there for absolutely no reason. However, if you are using a more adhoc parser than mine, I bet you might find that you just do need that "(gdb)" there! Bob Rossi