RE: Re: MI *stopped event with CLI commands

["Marc Khouzam" <marc.khouzam@ericsson.com>]

Nick Roberts wrote:
> 
> 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.

In async mode, this does happens because proceed(...) returns immediately and everything
gets undone nicely.  But when async is off proceed(...) blocks with the code:
  if (!target_can_async_p ())
    {
      wait_for_inferior (0);
      normal_stop ();
    }

Since normal_stop() is called directly from proceed(...) the uiout is still set to CLI 
in this case, and the information of the *stopped event is created in a CLI format, which 
explains why *stopped has no information.

So, if I understood all this right, I think the uiout should be reset before calling
normal_stop().  I'm sure this is an over-simplification, but I hope it can point
in the right direction for this bug.

Thanks

Marc