This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
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