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/pthreads.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.

-- 
Pedro Alves