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


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