This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI non-stop mode spec


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?

> 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.

> > At one point, I would parse all of the output of gdb/mi that came
> > from running 'make check' in the gdb.mi testsuite. If you would like,
> > I could do that again after your patch, and let you know where it
> > breaks.
> 
> That would be good, thanks.

Ok, I'll do that once we have resolved what you expect the grammar to
be.

Bob Rossi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]