GDB/MI output command documentation error

GDB/MI output command documentation error

[Bob Rossi]

Hi,

The documentation for a GDB/MI output command says,

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

Where an out-of-band-record is one or more lines starting with
* + = (for async records)
~ @ & (for stream records)

A result record starts with a ^ (if no token is used).
The result record is after the possible out-of-band-records.

This Documentation is incorrect for the most basic GDB/MI command.
When I provide the GDB/MI command, -exec-run I get the following output.
    =library-unloaded,...
    =library-unloaded,...
    =thread-group-started,...
    =thread-created,...
    ^running                <- Incorrect location or docs are wrong
    *running,...
    (gdb)

In mi-interp.c:mi_on_resume the code says:
  /* To cater for older frontends, emit ^running, but do it only once
     per each command.  We do it here, since at this point we know
     that the target was successfully resumed, and in non-async mode,
     we won't return back to MI interpreter code until the target
     is done running, so delaying the output of "^running" until then
     will make it impossible for frontend to know what's going on.

     In future (MI3), we'll be outputting "^done" here.  */ 
  if (!running_result_record_printed && mi_proceeded)
    {
      fprintf_unfiltered (raw_stdout, "%s^running\n",
              current_token ? current_token : "");
    }

So, I assume we aren't going to change what GDB outputs at this point.
For that reason, I would argue the documentation is wrong.

The correct grammar would be something like,
output ==>
  ( out-of-band-record )* [ result-record ] ( out-of-band-record )* "(gdb)" nl 

Right?

Thanks,
Bob Rossi

Re: GDB/MI output command documentation error

[Vladimir Prus]

On 05/23/2014 05:26 AM, Bob Rossi wrote:
> Hi,
>
> The documentation for a GDB/MI output command says,
>
> output ==>
>      ( out-of-band-record )* [ result-record ] "(gdb)" nl
>
> Where an out-of-band-record is one or more lines starting with
> * + = (for async records)
> ~ @ & (for stream records)
>
> A result record starts with a ^ (if no token is used).
> The result record is after the possible out-of-band-records.
>
> This Documentation is incorrect for the most basic GDB/MI command.
> When I provide the GDB/MI command, -exec-run I get the following output.
>      =library-unloaded,...
>      =library-unloaded,...
>      =thread-group-started,...
>      =thread-created,...
>      ^running                <- Incorrect location or docs are wrong
>      *running,...
>      (gdb)
>
> In mi-interp.c:mi_on_resume the code says:
>    /* To cater for older frontends, emit ^running, but do it only once
>       per each command.  We do it here, since at this point we know
>       that the target was successfully resumed, and in non-async mode,
>       we won't return back to MI interpreter code until the target
>       is done running, so delaying the output of "^running" until then
>       will make it impossible for frontend to know what's going on.
>
>       In future (MI3), we'll be outputting "^done" here.  */
>    if (!running_result_record_printed && mi_proceeded)
>      {
>        fprintf_unfiltered (raw_stdout, "%s^running\n",
>                current_token ? current_token : "");
>      }
>
> So, I assume we aren't going to change what GDB outputs at this point.
> For that reason, I would argue the documentation is wrong.
>
> The correct grammar would be something like,
> output ==>
>    ( out-of-band-record )* [ result-record ] ( out-of-band-record )* "(gdb)" nl

Bob,

I think that it probably was wrong to define 'output' nonterminal in the first place. While your revision
makes things closer to reality, out of band records don't necessary correspond to any command,
therefore making them a part of command output in the grammar is not logically reasonable. In fact,
I think that out of band record can appear outside command output - say, you did -exec-step, it
completed and you have the prompt, but in non-stop mode, other threads can hit breakpoints producing
*stopped. In fact, in non-stop/async mode you get prompt even while the current command is still running.

Better approach would to be to say that each thing GDB outputs is a sequence of line, and each
line can be parsed as either out of band record or result record or prompt. Other constraints,
such as single-result-record-per-command would be described outside of the grammar.

What do you think?

- Volodya