This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI output command error
- From: Karganov Konstantin <kostik at ispras dot ru>
- To: Bob Rossi <bob at brasko dot net>
- Cc: GDB <gdb at sources dot redhat dot com>
- Date: Thu, 10 Mar 2005 18:06:13 +0300 (MSK)
- Subject: Re: MI output command error
> 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.