This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI output command error
On Thu, Mar 10, 2005 at 05:06:35PM +0300, Karganov Konstantin wrote:
>
> > > If I were the GDB maintainer, I'd answer the following:
> > > All "execution" commands (continue, step, next, etc) are partially
> > > asynchronous - in the sence that when the execution is started you can
> > > type a characters to inferior stdin. In this case you need a way to know
> > > when the inferior starts/stops execution.
> >
> > Are you suggesting that you are using the MI with putting the inferior
> > on a separate pty?
>
> I suppose, that it is implemented in the same way. I mean that redirection
> of inferior's I/O makes just redirection and doesnt affect the way in
> which gdb command processing is done.
>
> And it should be independent of tty redirection!
> You will be scolding first if after using "tty" command the
> ^running/*stopped will change to *running/^stopped... :)
haha :)
No, seriously though. 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.
Thanks,
Bob Rossi