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 Wednesday 19 March 2008 17:05:31 Bob Rossi wrote:
> 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?

"called"? If you mean, printed, then yes. Which is also the case
today -- each (gdb) is part of new 'output' nonterminal.

> 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 probably miss something -- why would we want to add such a top-level
rule?

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

There are no pointers, I'm afraid. But basically, MI output is a number
of lines. Frontend first parses each line individually. Then
depending on what kind of line it was it can either:

1. For a result-record line, it declares that some command is done,
and invokes processing relevant to that command.
2. For out-of-band-record it updates the internal state, accordingly
to the out-of-band-record.
3. For prompt, it records that it's now OK to send new commands to GDB
(and expect GDB to process a command immediately).

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

Sorry, what problem is here? The MI output is designed in such a way that
the frontend can, and should, ignore things it does not understand. So,
if .gdbinit causes program to run, and some async notification to be printed,
and the frontend does not understand those, well, it does not understand those.
Things only matter if we change the meaning of some of MI output in a backward
incompatible way.

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

What should MI2 capable frontend to is GDB reports MI7?

- Volodya


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