gdb-mi and debugging interactive programs

[Eli Zaretskii]

Can someone (Nick?) who knows the details of how gdb-mi and GDB set up
the standard handles of both GDB itself and the debuggee please look
at bug #12163?

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12163

(The end of the discussion is in bug 12180, for some reason.)

I only studied this in detail on MS-Windows, and there the situation
looks hopeless (unless one uses "set new-console on" before running
the debuggee) when you try to debug a program that reads stdin and
writes its stdout.  It seems like gdb-mi sends commands to GDB
regardless of whether GDB is ready to receive them.  AFAIK, the only
safe time to send a command to GDB is after we receive the "(gdb) "
prompt.  But gdb-mi does not do that, it generally sends commands like
"-thread-info" whenever it feels like it.  That causes those commands
to be read by the debuggee as input, instead of giving the user chance
to type input.  And if the user eventually succeeds to type input for
the program, gdb-mi wraps it in "-interpreter-exec console", which of
course ruins the whole interaction.

Similarly with output: if the debuggee happens to output text that
looks like GDB/MI output records, gdb-mi interprets that as if it came
from GDB.  E.g., try debugging a program that writes something like
'*stopped,reason="exited"' to its stdout: in my experiments, gdb-mi
decided that the program exited.

How is this supposed to work? how is gdb-mi supposed to distinguish
between I/O with GDB and I/O with a program being debugged?  That is,
if the user types some text into the gud buffer, how can gdb-mi know
whether to send it to GDB or to the debuggee?  What am I missing here?

TIA