Re: MI output command error

Bob Rossi
2005-03-10T14:40:24Z

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