GDB/MI Output syntax

GDB/MI Output syntax

[Bob Rossi]

Hi,

Below is a patch that adds a much needed newline into the
out-of-band-record. This makes the grammar match the output of GDB and
was hinted to that it was just a typo to not have it there.

Permission to apply?

Thanks,
Bob Rossi

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.212
diff -w -u -r1.212 gdb.texinfo
--- gdb.texinfo 30 Jul 2004 19:23:54 -0000      1.212
+++ gdb.texinfo 24 Aug 2004 19:17:49 -0000
@@ -14674,7 +14674,7 @@
 @code{ [ @var{token} ] "^" @var{result-class} ( "," @var{result} )* @var{nl}}

 @item @var{out-of-band-record} @expansion{}
-@code{@var{async-record} | @var{stream-record}}
+@code{( @var{async-record} | @var{stream-record} ) @var{nl}}

 @item @var{async-record} @expansion{}
 @code{@var{exec-async-output} | @var{status-async-output} | @var{notify-async-output}}

Re: GDB/MI Output syntax

[Michael Chastain]

Bob Rossi <bob@brasko.net> wrote:
> -@code{@var{async-record} | @var{stream-record}}
> +@code{( @var{async-record} | @var{stream-record} ) @var{nl}}

I'm dubious about this.

stream-record does not have an NL terminator and needs one, yes.

But async-record already gets an NL terminator in the grammar
and does not need a second one.

  async-record -> exec-async-output | status-async-output | notify-async-output
  exec-async-output -> [token] "*" async-output
  async-output -> async-class ("," result)* nl

For example, gdb.mi/gdb669.exp gives:

  # gdb.log excerpt
  ~"[Thread debugging using libthread_db enabled]\n"
  ~"[New Thread 8192 (LWP 26606)]\n"
  ~"[Switching to Thread 8192 (LWP 26606)]\n"
  000*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x0804852d",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff814"}],file="/berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.mi/pthreads.c",line="81"}
  (gdb) 

Re: GDB/MI Output syntax

[Bob Rossi]

On Tue, Aug 24, 2004 at 03:33:30PM -0400, Michael Chastain wrote:
> Bob Rossi <bob@brasko.net> wrote:
> > -@code{@var{async-record} | @var{stream-record}}
> > +@code{( @var{async-record} | @var{stream-record} ) @var{nl}}
> 
> I'm dubious about this.
> 
> stream-record does not have an NL terminator and needs one, yes.
> 
> But async-record already gets an NL terminator in the grammar
> and does not need a second one.
> 
>   async-record -> exec-async-output | status-async-output | notify-async-output
>   exec-async-output -> [token] "*" async-output
>   async-output -> async-class ("," result)* nl
> 
> For example, gdb.mi/gdb669.exp gives:
> 
>   # gdb.log excerpt
>   ~"[Thread debugging using libthread_db enabled]\n"
>   ~"[New Thread 8192 (LWP 26606)]\n"
>   ~"[Switching to Thread 8192 (LWP 26606)]\n"
>   000*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x0804852d",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff814"}],file="/berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.mi/pthreads.c",line="81"}
>   (gdb) 

Thanks again. I stand corrected.
We could do, 
   out-of-band-record ==>
       async-record | stream-record newline

does that sound correct?

Thanks,
Bob Rossi

Re: GDB/MI Output syntax

[Bob Rossi]

On Tue, Aug 24, 2004 at 03:39:28PM -0400, Bob Rossi wrote:
> On Tue, Aug 24, 2004 at 03:33:30PM -0400, Michael Chastain wrote:
> > Bob Rossi <bob@brasko.net> wrote:
> > > -@code{@var{async-record} | @var{stream-record}}
> > > +@code{( @var{async-record} | @var{stream-record} ) @var{nl}}
> > 
> > I'm dubious about this.
> > 
> > stream-record does not have an NL terminator and needs one, yes.
> > 
> > But async-record already gets an NL terminator in the grammar
> > and does not need a second one.
> > 
> >   async-record -> exec-async-output | status-async-output | notify-async-output
> >   exec-async-output -> [token] "*" async-output
> >   async-output -> async-class ("," result)* nl
> > 
> > For example, gdb.mi/gdb669.exp gives:
> > 
> >   # gdb.log excerpt
> >   ~"[Thread debugging using libthread_db enabled]\n"
> >   ~"[New Thread 8192 (LWP 26606)]\n"
> >   ~"[Switching to Thread 8192 (LWP 26606)]\n"
> >   000*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x0804852d",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff814"}],file="/berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.mi/pthreads.c",line="81"}
> >   (gdb) 
> 
> Thanks again. I stand corrected.
> We could do, 
>    out-of-band-record ==>
>        async-record | stream-record newline
> 
> does that sound correct?

otherwise if you prefer to have the newline at the bottom of the chain
we could just do 
   console-stream-output ==>
       "~" c-string nl

   target-stream-output ==>
       "@" c-string nl

   log-stream-output ==>
       "&" c-string nl

The first solution is shorter, the second solution is more obvious to
the eye.

Bob Rossi

Re: GDB/MI Output syntax

[Michael Chastain]

Bob Rossi <bob@brasko.net> wrote:

   out-of-band-record ==>
       async-record | stream-record newline

Yikes.  That looks correct, but ugly.  An async-record includes its own
newline, but a stream-record doesn't!  That's gonna be a maintenance
annoyance.

That's just the micro-level feedback.  On a higher level, I think it
would be better to let go of the micro-patches and spend some time
making up an integrated plan.

(And I'd be happy to contribute my two hundred cents if you want ideas
 for a plan).

Re: GDB/MI Output syntax

[Andrew Cagney]

> Bob Rossi <bob@brasko.net> wrote:
> 
>>> -@code{@var{async-record} | @var{stream-record}}
>>> +@code{( @var{async-record} | @var{stream-record} ) @var{nl}}
> 
> 
> I'm dubious about this.
> 
> stream-record does not have an NL terminator and needs one, yes.
> 
> But async-record already gets an NL terminator in the grammar
> and does not need a second one.

That's kind of why, per my earlier post, I suggested moving all the 
@var{nl} to the @var{output} production.  That way we can see exactly 
where they fit in.

Andrew

>   async-record -> exec-async-output | status-async-output | notify-async-output
>   exec-async-output -> [token] "*" async-output
>   async-output -> async-class ("," result)* nl
> 
> For example, gdb.mi/gdb669.exp gives:
> 
>   # gdb.log excerpt
>   ~"[Thread debugging using libthread_db enabled]\n"
>   ~"[New Thread 8192 (LWP 26606)]\n"
>   ~"[Switching to Thread 8192 (LWP 26606)]\n"
>   000*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x0804852d",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff814"}],file="/berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.mi/pthreads.c",line="81"}
>   (gdb) 
> 
> 

Re: GDB/MI Output syntax

[Bob Rossi]

On Tue, Aug 24, 2004 at 03:46:52PM -0400, Andrew Cagney wrote:
> >Bob Rossi <bob@brasko.net> wrote:
> >
> >>>-@code{@var{async-record} | @var{stream-record}}
> >>>+@code{( @var{async-record} | @var{stream-record} ) @var{nl}}
> >
> >
> >I'm dubious about this.
> >
> >stream-record does not have an NL terminator and needs one, yes.
> >
> >But async-record already gets an NL terminator in the grammar
> >and does not need a second one.
> 
> That's kind of why, per my earlier post, I suggested moving all the 
> @var{nl} to the @var{output} production.  That way we can see exactly 
> where they fit in.

I don't think it would be possible to move all of the @var{nl} to the
output production. Not without making the output production very large.
This is because in several case's the newline is only outputted
conditionally, since some productions are optional.

I think the simple patch would be fine for now. Do you agree?

Thanks,
Bob Rossi

Re: GDB/MI Output syntax

[Bob Rossi]

On Tue, Aug 24, 2004 at 03:46:52PM -0400, Andrew Cagney wrote:
> >Bob Rossi <bob@brasko.net> wrote:
> >
> >>>-@code{@var{async-record} | @var{stream-record}}
> >>>+@code{( @var{async-record} | @var{stream-record} ) @var{nl}}
> >
> >
> >I'm dubious about this.
> >
> >stream-record does not have an NL terminator and needs one, yes.
> >
> >But async-record already gets an NL terminator in the grammar
> >and does not need a second one.
> 
> That's kind of why, per my earlier post, I suggested moving all the 
> @var{nl} to the @var{output} production.  That way we can see exactly 
> where they fit in.

Andrew, were you suggesting something like this?

from
   output ==> ( out-of-band-record )* [ result-record ] "(gdb)" nl
to
   output ==> (out-of-band-record nl)* [ result-record nl] "(gdb)" nl

and removing the 'nl' everywhere else?

That might actually work. Although, I don't personally know a way of
changing a grammar and guaranteeing that there the same.

Bob Rossi

Re: GDB/MI Output syntax

[Andrew Cagney]

> On Tue, Aug 24, 2004 at 03:46:52PM -0400, Andrew Cagney wrote:
> 
>>>> >Bob Rossi <bob@brasko.net> wrote:
>>>> >
>>>
>>>>>> >>>-@code{@var{async-record} | @var{stream-record}}
>>>>>> >>>+@code{( @var{async-record} | @var{stream-record} ) @var{nl}}
>>>
>>>> >
>>>> >
>>>> >I'm dubious about this.
>>>> >
>>>> >stream-record does not have an NL terminator and needs one, yes.
>>>> >
>>>> >But async-record already gets an NL terminator in the grammar
>>>> >and does not need a second one.
>>
>>> 
>>> That's kind of why, per my earlier post, I suggested moving all the 
>>> @var{nl} to the @var{output} production.  That way we can see exactly 
>>> where they fit in.
> 
> 
> Andrew, were you suggesting something like this?
> 
> from
>    output ==> ( out-of-band-record )* [ result-record ] "(gdb)" nl
> to
>    output ==> (out-of-band-record nl)* [ result-record nl] "(gdb)" nl
> 
> and removing the 'nl' everywhere else?

Yep.

> That might actually work. Although, I don't personally know a way of
> changing a grammar and guaranteeing that there the same.

A series of rewrites where NL is slow pushed down should eventually 
result in the old grammar (well except that it would be fixed).

Andrew

Re: GDB/MI Output syntax

[Bob Rossi]

On Tue, Aug 24, 2004 at 04:16:44PM -0400, Andrew Cagney wrote:
> >On Tue, Aug 24, 2004 at 03:46:52PM -0400, Andrew Cagney wrote:
> >
> >>>>>Bob Rossi <bob@brasko.net> wrote:
> >>>>>
> >>>
> >>>>>>>>>-@code{@var{async-record} | @var{stream-record}}
> >>>>>>>>>+@code{( @var{async-record} | @var{stream-record} ) @var{nl}}
> >>>
> >>>>>
> >>>>>
> >>>>>I'm dubious about this.
> >>>>>
> >>>>>stream-record does not have an NL terminator and needs one, yes.
> >>>>>
> >>>>>But async-record already gets an NL terminator in the grammar
> >>>>>and does not need a second one.
> >>
> >>>
> >>>That's kind of why, per my earlier post, I suggested moving all the 
> >>>@var{nl} to the @var{output} production.  That way we can see exactly 
> >>>where they fit in.
> >
> >
> >Andrew, were you suggesting something like this?
> >
> >from
> >   output ==> ( out-of-band-record )* [ result-record ] "(gdb)" nl
> >to
> >   output ==> (out-of-band-record nl)* [ result-record nl] "(gdb)" nl
> >
> >and removing the 'nl' everywhere else?
> 
> Yep.
> 
> >That might actually work. Although, I don't personally know a way of
> >changing a grammar and guaranteeing that there the same.
> 
> A series of rewrites where NL is slow pushed down should eventually 
> result in the old grammar (well except that it would be fixed).

By the way you are talking, I can't tell if you are going to do this, or
if you expect someone else to do it?

Should I just post a new grammar with the suggestion? The problem is, I
don't know how to prove that the new grammar is equivalant to the old
grammar. Is there a way to do that?


Thanks,
Bob Rossi

Re: GDB/MI Output syntax

[Andrew Cagney]

>>>> >Andrew, were you suggesting something like this?
>>>> >
>>>> >from
>>>> >   output ==> ( out-of-band-record )* [ result-record ] "(gdb)" nl
>>>> >to
>>>> >   output ==> (out-of-band-record nl)* [ result-record nl] "(gdb)" nl
>>>> >
>>>> >and removing the 'nl' everywhere else?
>>
>>> 
>>> Yep.
>>> 
>>
>>>> >That might actually work. Although, I don't personally know a way of
>>>> >changing a grammar and guaranteeing that there the same.
>>
>>> 
>>> A series of rewrites where NL is slow pushed down should eventually 
>>> result in the old grammar (well except that it would be fixed).
> 
> 
> By the way you are talking, I can't tell if you are going to do this, or
> if you expect someone else to do it?

I eye balled it - it puts a NL at the end of each record which was the 
intent.

> Should I just post a new grammar with the suggestion? The problem is, I
> don't know how to prove that the new grammar is equivalant to the old
> grammar. Is there a way to do that?

Well, to be pedantic, the old grammer contained a bug which this fixes 
so we can't prove equivalence.  However using a sequence of 
transformations (rewrite was a poor choice of word) we can show rough 
equivalence.  For instance:

> @item @var{output} @expansion{}
> @code{( @var{out-of-band-record} @var{nl} )* [ @var{result-record} @var{nl} ] "(gdb)" @var{nl}}
> 
> @item @var{result-record} @expansion{}
> @code{[ @var{token} ] "^" @var{result-class} ( "," @var{result} )*}

Moving result-record's NL into the result-record production yields:

> @item @var{output} @expansion{}
> @code{( @var{out-of-band-record} @var{nl})* [ @var{result-record} ] "(gdb)" @var{nl}}
> 
> @item @var{result-record} @expansion{}
> @code{ [ @var{token} ] "^" @var{result-class} ( "," @var{result} )* @var{nl}}

which is the easy one done.  The other while longer and more tedious is 
similar except it ends up pushing an NL down into stream-record (where 
it was missing).

Is this what you ment?

Andrew

Re: GDB/MI Output syntax

[Eli Zaretskii]

> Date: Tue, 24 Aug 2004 15:19:31 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Below is a patch that adds a much needed newline into the
> out-of-band-record. This makes the grammar match the output of GDB and
> was hinted to that it was just a typo to not have it there.
> 
> Permission to apply?

I understand that you've withdrawn this patch.  If not, and if you
still want my approval, please explain what does the extra level of
parens stand for and why did you leave whitespace inside it.