This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI/RFC] Emit ^running via observer.
On Friday 27 June 2008 04:14:18 Nick Roberts wrote:
> > > 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.
That's the question -- what about this test is specific to async 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.
Not mine, unfortunately. We can't even make all target always have at least
one element in thread list -- which is much simpler change.
- Volodya