From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14731 invoked by alias); 19 Mar 2008 13:50:53 -0000 Received: (qmail 14719 invoked by uid 22791); 19 Mar 2008 13:50:51 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 13:50:31 +0000 Received: (qmail 15857 invoked from network); 19 Mar 2008 13:50:29 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Mar 2008 13:50:29 -0000 From: Vladimir Prus To: Bob Rossi Subject: Re: MI non-stop mode spec Date: Wed, 19 Mar 2008 14:07:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sources.redhat.com References: <200803190016.02072.vladimir@codesourcery.com> <200803191419.39958.vladimir@codesourcery.com> <20080319134134.GH12641@brasko.net> In-Reply-To: <20080319134134.GH12641@brasko.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803191650.28263.vladimir@codesourcery.com> 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/msg00159.txt.bz2 On Wednesday 19 March 2008 16:41:34 Bob Rossi wrote: > On Wed, Mar 19, 2008 at 02:19:39PM +0300, Vladimir Prus wrote: > > On Wednesday 19 March 2008 14:09:38 Bob Rossi wrote: > > > On Wed, Mar 19, 2008 at 12:16:01AM +0300, Vladimir Prus wrote: > > > > > > > > Making good used of GDB in async mode, and especially in async non-stop > > > > mode demands some changes in MI -- both general clarifications, and actual > > > > work to allow most MI commands while the target is running and define > > > > their behaviour. > > > > > > Do you mind posting an updated grammar for the GDB/MI changes that you > > > are making? or at least just a diff of it? > > > > The following changes will happen: > > output ==> > > ( out-of-band-record )* [ result-record ] "(gdb)" nl > > becomes: > > output ==> > > ( out-of-band-record | result-record | "(gdb)" ) nl > > OK, something seems wrong here. > > Previously, you could have 0 or more out-of-band-records. That could be > followed by a result-record, but didn't have to be, and then the obvious > "(gdb)" nl. > > Now you are saying you must have 1 out-of-band-record followed by 1 result-record. > Is this what you intended to say? I mean, currently, how would that > support handling multiples lines of output from the inferior on stdout? 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. > > > then > > async-class ==> > > "stopped" | others (where others will be added depending on the needs--this is still in development). > > becomes: > > async-class ==> > > "stopped" | "running" | "thread-created" | others (where others will be added depending on the needs--this is still in development). > > OK, makes perfect sense. > > > > I currently maintain a gdb/mi bison parser that i have not put into > > > production use yet. However, the time for this is coming, I will > > > probably start working on this again after all of these changes get > > > through. > > > > Except for the 'output' change -- which essentially codifies that > > MI output is a sequence of almost independent lines, I don't think > > there are further changes to the grammar planned except for adding > > new async-classes. > > 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. - Volodya