This is the mail archive of the 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: GDB/MI output command documentation error

On 05/23/2014 05:26 AM, Bob Rossi wrote:

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.
     ^running                <- Incorrect location or docs are wrong

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


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

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