A Thursday 10 April 2008 21:02:07, Pedro Alves wrote:
> Running the testsuite in linux native async mode in
> an x86_64-unknown-linux-gnu with -m32 to simulate an x86-pc-linux-gnu,
> I get a bunch of MI testsuite errors related to this difference of
> output in async vs sync modes:
>
> async:
>
> 220^running
> &"warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at
> ffffe0b4\n"
> (gdb)
>
> sync:
>
> 220^running
> (gdb)
> &"warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at
> ffffe0b4\n"
>
>
> It results in errors that look like these:
>
> 220-exec-run
> 220^running
> &"warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at
> ffffe0b4\n"
> (gdb)
> ~"[Thread debugging using libthread_db enabled]\n"
> 220*stopped,thread-id="1",frame={addr="0x08048542",func="main",args=[],file
>="../../../src/gdb/testsuite/gdb.mi/pth
> reads.c",fullname="/home/pedro/gdb/track_mi/src/gdb/testsuite/gdb.mi/pthrea
>ds.c",line="79"} (gdb)
> ERROR: Unable to start target
>
> The difference comes from the fact that on sync mode, the MI prompt is
> output immediatelly after ^running, while on async mode, it is output a bit
> later.
>
>   if (!target_can_async_p ())
>     {
>       /* NOTE: For synchronous targets asynchronous behavour is faked by
>          printing out the GDB prompt before we even try to execute the
>          command.  */
>       if (last_async_command)
> 	fputs_unfiltered (last_async_command, raw_stdout);
>       fputs_unfiltered ("^running\n", raw_stdout);
>       fputs_unfiltered ("(gdb) \n", raw_stdout);
>       gdb_flush (raw_stdout);
>     }
>   else
>     {
>       /* FIXME: cagney/1999-11-29: Printing this message before
>          calling execute_command is wrong.  It should only be printed
>          once gdb has confirmed that it really has managed to send a
>          run command to the target.  */
>       if (last_async_command)
> 	fputs_unfiltered (last_async_command, raw_stdout);
>       fputs_unfiltered ("^running\n", raw_stdout);
>     }
>
> The async case looks more correct than the sync one, so I propose fixing
> the regex to match warnings before the MI prompt.
>
> It is also arguable if that warning has any value, but in any case,
> we should be filtering warnings.
>
> Fixing this leaves me with one MI regression, mi-pending.exp, which is
> related to throwing an exception running the exec cleanups, which deletes
> the MI token, when it shouldn't.  That is fixed by Vladimir's pending
> "murder exec cleanup" patch, or when the token in *stopped is removed.
> Both will go in very soon.


Ahem, that regex will probably eat to much, cli errors as well.  It
isn't because it's called mi_warnings that it will only
filter warnings (blush).

Updated patch attached.

-- 
Pedro Alves