Fix MI/async testsuite

[Vladimir Prus]

On Sunday 04 May 2008 23:56:40 Daniel Jacobowitz wrote:
> On Sun, May 04, 2008 at 09:38:01PM +0400, Vladimir Prus wrote:
> > Well, ideally, ^running should not exist. When gdb is done with a command,
> > it should always print ^done, and since it's done with a command, print a
> > prompt. Unfortunately, right now ^running exists and does something fairly
> > strange:
> > 
> > - in sync mode, you get "^running" + "(gdb)" before even trying to resume
> > target
> > - in async mode you get "^running" + random output + "(gdb)"
> > - in async mode when running CLI command, you get "^running" + "^done"
> > 
> > This is a mess, but I don't think we should/can fix this mess without
> > going to MI3.
> 
> For MI2, why can't we leave ^running 

We can't "leave" it, because in async mode ^running is not immediately followed
by a prompt, now, and before any my changes. 

> always followed by a prompt?  We 
> fail to accept input at that prompt in sync mode, which is a known
> bug, but that's life.

I sure can make all ^running be followed by prompt, but that would be "fixing"
code to be as buggy as the other code. Does it worth the time?

> I don't think having ^result followed by =EVENT followed by (gdb)
> makes sense, 

I think it does -- and the MI spec I've just posted explicitly calls for
such behaviour for run commands:

1. First you get ^done, which means "Okay, nothing else to do about this command"
2. Then you get *running, =whatever, ..., *stopped

In async mode, you get prompt immediately after (1) -- because it's where gdb
is ready to accept commands. In sync mode, you get prompt after (2). Of course,
we can print ^done only after (2) in that case, but does it make sense?

- Volodya