RE: Re: MI *stopped event with CLI commands

[Nick Roberts <nickrob@snap.net.nz>]

 > > set target-async on
 > > 
 > > first, you do get the full information.  Perhaps this should be the default
 > > for targets which can run asynchronously.
 > 
 > Vladimir Prus wrote:
 > >
 > > Probably. Though it does not change the fact that *stopped without details
 > > sounds like a bug. I'll take a look, though it might take a few days.
 > 
 > I looked into the fact that *stopped worked properly with async on but not
 > with async off (thanks Nick.)  My understanding of GDB internals is quite
 > limited, but I believe what is happening is the following:
 > 
 > When issuing a command that resumes the inferior, say -exec-continue or
 > continue, we eventually end up in method proceed(...) of infrun.c On the
 > call chain to that method, if the command that resumed the inferior was a
 > CLI command (e.g. continue) the uiout structure has been forced to be the
 > CLI uiout; this makes sense to me since we want any output of the CLI
 > command to be formatted as CLI output.  However, once the inferior stops,
 > the output that follows should no longer be in CLI format, I believe.  So,
 > after the inferior is resumed, we should probably go back to the MI uiout.
 >...

I imagine that you can get MI-like output from a CLI execution command by
switching uiout at critical places but asynchronous mode seems to me to
be the natural way to do it as it decouples GDB output from the command
that started the execution, be it MI or CLI.

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