MI testsuite fix

[Pedro Alves]

A Thursday 10 April 2008 21:36:42, Luis Machado escreveu:

> There is an additional failure in the MI testsuite (PPC) when running in
> asynch mode, mi-simplerun.exp and mi2-simplerun.exp, which seems to be
> an output ordering issue as well.
>
> "Correct" output:
> 220-exec-continue^M
> 220^running^M
> (gdb) ^M
> Hello, World!callme^M
> callme^M
> 220*stopped,reason="exited-normally"^M
> (gdb) ^M
> PASS: gdb.mi/mi-simplerun.exp: continue to end
>
> "Incorrect" output:
> 220-exec-continue^M
> 220^running^M
> Hello, World!callme^M
> callme^M
> (gdb) ^M
> FAIL: gdb.mi/mi-simplerun.exp: continue to end (failed to resume)
>
> Correct and incorrect between "" because both ending results are valid.
>
> This is not fixed by your latest patch, Pedro. What do you think?
>

Ah, this is the one I had already analized here:
http://sourceware.org/ml/gdb-patches/2008-03/msg00293.html

The issue is that there is a race between gdb printing (gdb)
and the inferior starting to print too.  In sync mode, you
don't see it, because ^running and (gdb) and output before
starting the target:

      fputs_unfiltered ("^running\n", raw_stdout);
      fputs_unfiltered ("(gdb) \n", raw_stdout);

I don't know if the protocol specifies when is it that
a frontend should expect that the inferior starts outputing
to the console.  (gdb) should mean GDB is ready for input,
not that the inferior started, right?  Maybe GDB should
wait for a *running notification instead of (GDB), but
even so, I'm not sure every target will emit it in 
single-threaded programs.  So, to me this looks like
a testsuite deficiency.  Perhaps we should just put
a sleep (1) at the start of that test.

-- 
Pedro Alves