Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: Bob Rossi <bob_rossi@cox.net>
Cc: gdb@sources.redhat.com
Subject: Re: MI non-stop mode spec
Date: Wed, 19 Mar 2008 16:09:00 -0000	[thread overview]
Message-ID: <200803191733.30054.vladimir@codesourcery.com> (raw)
In-Reply-To: <20080319140531.GI12641@brasko.net>

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


  reply	other threads:[~2008-03-19 14:33 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-19  2:49 Vladimir Prus
2008-03-19  6:26 ` Nick Roberts
2008-03-19  9:14   ` Vladimir Prus
2008-03-19 10:02     ` Nick Roberts
2008-03-19 11:10       ` Vladimir Prus
2008-03-19 12:30         ` Nick Roberts
2008-03-19 13:43           ` Vladimir Prus
2008-03-19 20:44       ` Michael Snyder
2008-03-19 11:20     ` Bob Rossi
2008-03-19 11:16 ` Bob Rossi
2008-03-19 12:01   ` Vladimir Prus
2008-03-19 13:50     ` Bob Rossi
2008-03-19 14:07       ` Vladimir Prus
2008-03-19 14:33         ` Bob Rossi
2008-03-19 16:09           ` Vladimir Prus [this message]
2008-03-20 18:22 ` Marc Khouzam
2008-03-20 20:02   ` Vladimir Prus
2008-03-21  9:11   ` Nick Roberts
2008-03-21  9:48     ` Vladimir Prus
2008-03-21 18:13       ` Nick Roberts
2008-03-22  0:33         ` Vladimir Prus
2008-03-23  4:41           ` Nick Roberts
2008-03-23  5:18             ` Vladimir Prus
2008-03-23  9:25               ` Nick Roberts
2008-03-24  5:44                 ` Vladimir Prus
2008-03-24  7:05                   ` Thread bound variable objects [was: Re: MI non-stop mode spec] Nick Roberts
2008-03-24  7:18                     ` Vladimir Prus
2008-03-24 11:04                       ` Nick Roberts
2008-03-24 14:38                         ` Vladimir Prus
2008-03-25  6:28                       ` Thread bound variable objects Nick Roberts
2008-03-25 11:34                         ` Daniel Jacobowitz
2008-03-21 11:52 ` MI non-stop mode spec Vladimir Prus
2008-03-24 23:14   ` Daniel Jacobowitz
2008-03-25 17:46     ` Vladimir Prus
2008-03-22 17:33 ` Pawel Piech
2008-03-24  4:03   ` Nick Roberts
2008-03-24 17:22     ` Pawel Piech
2008-03-24 20:23       ` Vladimir Prus
2008-03-25  2:14       ` Nick Roberts
2008-03-24 18:38   ` Vladimir Prus
2008-03-24 21:25     ` Pawel Piech
2008-03-24 21:46       ` Vladimir Prus
2008-03-24 22:28         ` Pawel Piech
2008-03-25 12:30           ` Vladimir Prus
2008-03-25 18:30             ` Pawel Piech
2008-03-27 14:13               ` Vladimir Prus
2008-03-27 19:39                 ` Pawel Piech
2008-03-25 21:28             ` Nick Roberts
2008-03-26 13:03               ` Pawel Piech
2008-03-25  1:00   ` Daniel Jacobowitz
2008-03-25 18:18     ` Pawel Piech
2008-03-30 21:36       ` Pawel Piech

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803191733.30054.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=bob_rossi@cox.net \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox