Fix MI/async testsuite

[Daniel Jacobowitz]

Sorry, I shouldn't have dropped this conversation.  Now I'm going to
have to figure out all the issues again...

On Mon, May 05, 2008 at 12:40:47PM +0400, Vladimir Prus wrote:
> On Sunday 04 May 2008 23:56:40 Daniel Jacobowitz wrote:
> > 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?

Working async mode is a new feature.  Previous releases of GDB always
had ^running followed by a prompt, and I think that's the right thing
to output if you're going to use ^running.

> > 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

Why is *running after ^done, anyway?

> 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?

There won't be any ^done will there?  ^running, (gdb), *stopped,
(gdb).  And in async mode I'd expect something like

-exec-start
*running
^done
(gdb)
[pause while things run]
*stopped
[I don't remember if we get a prompt here.]

-- 
Daniel Jacobowitz
CodeSourcery