Re: [MI/RFC] Emit ^running via observer.

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > The tests appear to fail now. 
 > 
 > Which tests? 

All three in mi-async.exp, at the moment.  I'll look at them more closely to
see if they are due to local changes.

 >  With unmodified CVS state, all MI tests pass for me both in sync
 > and async mode. But indeed, if I make mi-async.exp not force async mode, it
 > starts to fail....

mi-async.exp is a test for async mode, so is not expected to pass in sync mode.

 > > SYNC:
 > > 
 > > r
 > > &"r\n"
 > > ~"Starting program: /home/nickrob/myprog \n"
 > > =thread-created,id="1"
 > > ^running
 > > *running,thread-id="all"
 > > (gdb) 
 > > ~"\n"
 > > ~"Breakpoint 1, main (argc=1, argv=0xbf961424) at myprog.c:146\n"
 > > ~"146\tmain (int argc, char **argv) {\n"
 > > *stopped
 > > (gdb) 
 > 
 > ... in this way. 
 > 
 > > i.e no reason, frame, file, etc fields.  It's important for the console in
 > > a frontend that the CLI command generates the same MI output as the
 > > corresponding MI command.
 > 
 > Of course. This is pre-existing problem, though, and was present in gdb 6.8
 > -- except that we did not output neither ^running nor *stopped at all -- so
 > apparently making mi-async.exp not actually enable async mode is a bit
 > premature yet. The problem, it appears, is that while the CLI command
 > executes, 'uiout' is the CLI interpreter's uiout, not MI uiout. I'll
 > probably won't have time to work on this in next month, so patches welcome.

It's not a problem if async mode becomes the default, which is my
understanding.  In sync mode, t may be possible to switch to the underlying MI
interpreter while in "proceed" but I think that using async mode is cleaner and
I have no plans to make sync mode work in this way.

-- 
Nick                                           http://www.inet.net.nz/~nickrob