Re: MI output command error

Karganov Konstantin
2005-03-10T15:13:25Z

> 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.