document issue about GDB/MI output syntax

document issue about GDB/MI output syntax

[asmwarrior]

Hi, I just found in this page:
https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
The syntax is not correct:

console-stream-output ==>
    "~" c-string
target-stream-output ==>
    "@" c-string
log-stream-output ==>
    "&" c-string 

It should be:

console-stream-output ==>
    "~" c-string nl
target-stream-output ==>
    "@" c-string nl
log-stream-output ==>
    "&" c-string nl

There is a "nl" missing in those stream-record, right?

Thanks

Yuanhui Zhang

Re: document issue about GDB/MI output syntax

[Joel Brobecker]

> Hi, I just found in this page:
> https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
> The syntax is not correct:
> 
> console-stream-output ==>
>     "~" c-string
> target-stream-output ==>
>     "@" c-string
> log-stream-output ==>
>     "&" c-string 
> 
> It should be:
> 
> console-stream-output ==>
>     "~" c-string nl
> target-stream-output ==>
>     "@" c-string nl
> log-stream-output ==>
>     "&" c-string nl
> 
> There is a "nl" missing in those stream-record, right?

I haven't verified with actual behavior, but something doesn't
look right indeed. However, I am wondering if we shouldn't
put the "nl" at the end of each [...]-record rule. Looking
at the grammar as currently written, I think we have issues
with other records.

-- 
Joel

Re: document issue about GDB/MI output syntax

[asmwarrior]

On 2013-12-20 2:07, Joel Brobecker wrote:
>> Hi, I just found in this page:
>> https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
>> The syntax is not correct:
>>
>> console-stream-output ==>
>>     "~" c-string
>> target-stream-output ==>
>>     "@" c-string
>> log-stream-output ==>
>>     "&" c-string 
>>
>> It should be:
>>
>> console-stream-output ==>
>>     "~" c-string nl
>> target-stream-output ==>
>>     "@" c-string nl
>> log-stream-output ==>
>>     "&" c-string nl
>>
>> There is a "nl" missing in those stream-record, right?
> 
> I haven't verified with actual behavior, but something doesn't
> look right indeed. 

Here is the log I start gdb in MI under Windows


E:\code\opencv\debugxb>gdb --interpreter=mi
=thread-group-added,id="i1"
~"GNU gdb (GDB) 7.6.50.20131219-cvs\n"
~"Copyright (C) 2013 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\
nThis is free software: you are free to change and redistribute it.\nThere is NO
 WARRANTY, to the extent permitted by law.  Type \"show copying\"\nand \"show wa
rranty\" for details.\n"
~"This GDB was configured as \"mingw32\".\nType \"show configuration\" for confi
guration details."
~"\nFor bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
~"Find the GDB manual and other documentation resources online at:\n<http://www.
gnu.org/software/gdb/documentation/>.\n"
~"For help, type \"help\".\n"
~"Type \"apropos word\" to search for commands related to \"word\".\n"
(gdb)


You see there are "nl"s after each line of GDB's message.


However, I am wondering if we shouldn't
> put the "nl" at the end of each [...]-record rule. Looking
> at the grammar as currently written, I think we have issues
> with other records.
> 

I think the "nl" can be put in a high level rule. E.g.

out-of-band-record ==>
    (async-record | stream-record) "nl"

I'm not sure the above grammar is in correct format, just put the "nl" in the end of out-of-band-record.

Yuanhui Zhang

Re: document issue about GDB/MI output syntax

[Joel Brobecker]

> You see there are "nl"s after each line of GDB's message.

Thanks for doing the testing.

I think, at this point, that it's best to just send a doc update
to gdb-patches. Eli is extremely diligent in reviewing code, but
make sure to wait for either Eli or one of the maintainers to
explicitly double-check that the update better matches the code,
and that the code is doing what we wanted it to be (ie, that we're
not turning a bug into law :-)).

Intuitively, I very much doubt there is a bug in the code, but
it's easy to be careful - just need a little bit of quiet time
to think.

-- 
Joel