Re: MI output command error

[Bob Rossi <bob at brasko dot net>]

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