RE: MI output command error

["Dave Korn" <dave.korn@artimi.com>]

----Original Message----
>From: 'Bob Rossi'
>Sent: 10 March 2005 16:09

>>> That's why I think the output
>>> 
>>>    (gdb)
>>>    444-exec-continue
>>>    444*running
>>>    444*stopped...
>>>    (gdb)
>>> 
>>> is better.
>> 
>>   Well, you're wrong.  "running" is the output from the exec-continue
>> command and it is synchronous: the exec-continue command executes,
>> starts up the inferior, prints out "running", and is then complete.  At
>> that point the inferior is running, but regardless of that, gdb is ready
>> to take more commands and so should prompt you.
> 
> It is? It is still busy executing the inferior. I was under the
> impression GDB was somehow "busy" while executing the inferior. Is this
> not true?

  Hell no!  Gdb is waiting for input from you.  Send it a command - e.g.
"info program", which wouldn't need to tell you if the inferior was running
or stopped if it was only possible to send gdb commands while the inferior
was stopped.  Some things are disabled while the inferior is running, others
aren't.  Blimey, if you aren't aware of that it's no wonder this
conversation has been going at cross purposes!  Check the documentation,
take a look at the -async flag for example.  And read the section on "GDB/MI
result records", which makes it clear that if you see "^running" that means
that an asynchronous operation is under way but not completed.  Then read
the documentation under "GDB/MI Program control", where it explains that
-exec-continue is *asynchronous*.  Oh, wait a minute, you must have already
read that because you quoted the example from it.  Do you actually know what
the terms "asynchronous" and "synchronous" mean, or were you just kind of
skimming over bits that didn't make any sense to you as you read the docs?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....