Re: MI output command error

[Karganov Konstantin <kostik@ispras.ru>]

> Here is how I imagine a transaction between a FE and GDB.
> 
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"
>    -> FE sends a single MI input command
>    -> FE does I/O with inferior
>    -> GDB sends an MI output command
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"
> 
> So, the only time a FE would know that it is ready to send a command is
> when it reaches the "(gdb)". Is this the same model for you?
> 
> That's why I think the output
> 
>    (gdb)
>    444-exec-continue
>    444*running
>    444*stopped...
>    (gdb)
> 
> is better.

I suppose that no one is going to change the existing behavior

 444-exec-continue
 444^running
 (gdb)
 444*stopped
 (gdb)

at least for historical reasons. And again - for uniformity with the 
human-oriented gdb output and the case of sharing the tty with inferior. 

If so, I suggest the following model of interaction with gdb:

 -> FE starts gdb and reads its output (there could be startup error msgs)
 -> FE sends a MI command and waits for its completion
 -> gdb sends a sequence of responses (there can be an automatic displays, 
    for example. (oob_rec)* is really needed, there can be any 
    number of the messages!)
    we are waiting for ^-response.
    if we get ^running (for execution commands) we start waiting for 
    *stopped one.
    getting the response we always skip "(gdb)" line.

Meanwhile the inferior tty works independently (in other
thread/window of FE, for example). ANd it seems to me that making a FE 
over gdb you surely need to redirect the inferior I/O somewhere.

Konstantin.