From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25604 invoked by alias); 19 Mar 2008 14:07:15 -0000 Received: (qmail 25508 invoked by uid 22791); 19 Mar 2008 14:07:14 -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 14:06:55 +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 <0JXZ00A84DT8KWO2@vms042.mailsrvcs.net> for gdb@sources.redhat.com; Wed, 19 Mar 2008 09:05:33 -0500 (CDT) Received: from bob by black with local (Exim 4.67) (envelope-from ) id 1Jbyv6-0003hX-2U; Wed, 19 Mar 2008 10:05:32 -0400 Date: Wed, 19 Mar 2008 14:33:00 -0000 From: Bob Rossi Subject: Re: MI non-stop mode spec In-reply-to: <200803191650.28263.vladimir@codesourcery.com> To: Vladimir Prus Cc: gdb@sources.redhat.com Mail-followup-to: Vladimir Prus , gdb@sources.redhat.com Message-id: <20080319140531.GI12641@brasko.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <200803190016.02072.vladimir@codesourcery.com> <200803191419.39958.vladimir@codesourcery.com> <20080319134134.GH12641@brasko.net> <200803191650.28263.vladimir@codesourcery.com> 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/msg00160.txt.bz2 On Wed, Mar 19, 2008 at 04:50:27PM +0300, Vladimir Prus wrote: > > > The following changes will happen: > > > output ==> > > > ( out-of-band-record )* [ result-record ] "(gdb)" nl > > > becomes: > > > output ==> > > > ( out-of-band-record | result-record | "(gdb)" ) nl > > > The above grammar say that gdb outputs either: > > 1. out-of-band record, > 2. result record > 3. prompt > > and that any of those is followed by a newline. So, you can > have 100 out-of-band-records, followed by result record, followed by > prompt, followed by some more out-of-band records. > > The 'output' nonterminal does not describe all the output > that gdb might produce during entire run, it describes a single line > that gdb might output. Hmm, that's interesting. So you are suggesting that output will be called over and over, instead of once. Am I correct? Is it no longer possible to add a top level rule? ie. output ==> output_line* (some terminator) output_line ==> ( out-of-band-record | result-record | "(gdb)" ) nl I'm not sure how to rationalize about getting line after line, with no final response. Perhaps I need to entirely rethink what gdb/mi is, and how to model an api on top of it. Could you give me some pointers? > > OK, that's great. Please think about the request I'm going to make, I > > think it's very important. I think the first thing gdb should do is > > output a single line (a header) that tells the version that mi is going > > to use during this communication, and the current versions that the > > particular gdb supports. > > > > The more we bump the MI revisions, the more it is going to take time for > > front ends to continually start gdb, probing for the best version it > > supports. > > > > I can submit a patch for this, if you don't feel like doing it. > > We should see what the final changes will be. Probably, we can announce > them using the existing -list-features command and then add a mechanism > to enable new behaviour with a MI command. > > Of course, if that proves unsufficient, we can implement a command > to query the available MI versions, and switch to the desired one. hehe. Think of it like this, xml, html, all of these other great languages always tell you first what the protocol you are communicating with is using. I just want mi to do the same thing. It's WAY to late in the game to call -list-features. For all you know, the user has some stuff in his .gdbinit that get run, and MI starts spewing out. I'm sure we could play some games with the command line, to put our own .gdbinit command to run first, but that just seems overly complicated. We should, at a minimum, print out the current version of mi in a prolouge mi statement. Bob Rossi