Re: MI non-stop mode spec

[Vladimir Prus <vladimir@codesourcery.com>]

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