[Bug mi/16308] New: No "(gdb)" marker output after MI *stopped record

[Bug mi/16308] New: No "(gdb)" marker output after MI *stopped record

[richard.stuckey at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16308

            Bug ID: 16308
           Summary: No "(gdb)" marker output after MI *stopped record
           Product: gdb
           Version: 7.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mi
          Assignee: unassigned at sourceware dot org
          Reporter: richard.stuckey at intel dot com

The syntax defined for MI output at
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
states, both in the text and in the BNF, that a sequence of output records is
always terminated by the "(gdb)" string.

However, this string is not output after *stopped exec-async-output records.

This can be fixed by altering function mi_on_normal_stop in file
mi/mi-interp.c:

  fputs_unfiltered ("*stopped", raw_stdout);
  mi_out_put (mi_uiout, raw_stdout);
  mi_out_rewind (mi_uiout);
  mi_print_timing_maybe ();
  fputs_unfiltered ("\n", raw_stdout);
  fputs_unfiltered ("(gdb) \n", raw_stdout);     // fix
  gdb_flush (raw_stdout);
}


Unfortunately, this then results in an additional two hundred or so failures in
the gdb.mi section of the gdb test suite, mostly with error  "unknown output
after running", which is probably the unexpected "(gdb)" after *stopped
records.

----

After some discussion with a colleague, it is not clear to me when the "(gdb)"
should actually be output, and whether this is actually a bug.  I interpret the
"(gdb)" as being an easily-distinguishable EOT marker that tells the MI output
reader that it has a sequence of complete records which it can now parse, as
opposed to having an incomplete record because it has not yet read all that
record's data from the MI output stream.  Is that correct?

-- 
You are receiving this mail because:
You are on the CC list for the bug.