Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Bob Rossi <bob_rossi@cox.net>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb@sources.redhat.com
Subject: Re: MI non-stop mode spec
Date: Wed, 19 Mar 2008 11:20:00 -0000	[thread overview]
Message-ID: <20080319111534.GG12641@brasko.net> (raw)
In-Reply-To: <frqbl3$rpe$1@ger.gmane.org>

On Wed, Mar 19, 2008 at 09:25:39AM +0300, Vladimir Prus wrote:
> Nick Roberts wrote:
> 
> >  > (*) Current MI syntax says that any result record must be followed by a
> >  > prompt. For sync targets, this is wrong -- when gdb prints ^running
> >  > and resumes the target, it does not check for input, so (gdb) is misleading.
> >  > When the target stops, the *stopped message, followed by the prompt is
> >  > printed -- and it's at this point that gdb starts to accept the input
> >  > again. So, I propose to remove the prompt right after ^running for the
> >  > sync targets.
> > 
> > It's not a prompt, just a delimiter.  For a start it has a newline after it.
> > Furthermore if you change the prompt with "set prompt", it doesn't change.
> 
> Let's call (gdb) a "MI prompt", then. Given that each MI output is already
> terminated with a newline, (gdb) is not necessary to property parse MI
> output. Then, the question is that does (gdb) mean? If it does not mean 
> anything, it should be, ideally, just removed. And if it means anything,
> then what? Current behaviour is not consistent, but the code suggests
> that it's meant to indicate when GDB is ready for a new command. I think
> such a behaviour will be useful for a frontend.

Exactly, "(gdb)" means nothing except, 
  output ==>
      ( out-of-band-record )* [ result-record ] "(gdb)" nl
exactly that. It is the end of the output record. I can tell you that my
parser can probably handle not having (gdb) in it, because the "(gdb)"
isn't the end symbol, the newline is. In fact, look at my grammar here,
  output: 
    opt_oob_record_list opt_result_record OPEN_PAREN variable CLOSED_PAREN NEWLINE {

You can see that I could probably remove the 
  OPEN_PAREN variable CLOSED_PAREN
part, and simply look for the NEWLINE. In fact, if I remove them, I do
not get an error from bison.

So, yes, it is there for absolutely no reason. However, if you are using
a more adhoc parser than mine, I bet you might find that you just do
need that "(gdb)" there!

Bob Rossi


  parent reply	other threads:[~2008-03-19 11:16 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 [this message]
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
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=20080319111534.GG12641@brasko.net \
    --to=bob_rossi@cox.net \
    --cc=gdb@sources.redhat.com \
    --cc=vladimir@codesourcery.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