Re: linux native async mode support

[Pedro Alves <pedro@codesourcery.com>]

A Wednesday 19 March 2008 16:24:35, Luis Machado wrote:
> Hi folks,
>
> I've ran the testsuite on PPC to check for regressions due to the async
> patch. The results look good, just the expected regressions and one
> unexpected (mi2-simplerun.exp).
>

Thanks both for testing, and thanks Luis for sending me the full logs!

> mi2-simplerun.exp:
> FAIL: gdb.mi/mi2-simplerun.exp: continue to end (1)
>
> Nick, i still can reproduce the last one constantly.

> >
> > 999-exec-continue
> > 999^running
> > Hello, World!callme
> > callme
> > (gdb)
> > 999*stopped,reason="exited-normally"
> > (gdb)
> > FAIL: gdb.mi/mi2-simplerun.exp: continue to end (1)
> >

I've looked at this failure, and what happens is that
in sync mode, gdb prompts "(gdb)" immediatelly
after printing "^running", while in async mode,
"^running" is output first, and only when "run" cli command
actually completes, the "(gdb) " is output.  Like so:

mi_execute_command
 captured_mi_execute_command
  mi_execute_async_cli_command
   mi_cmd_execute
    mi_cmd_exec_run
     mi_execute_async_cli_command 
      sets up continuation for "*stopped", if async mode.
      execute_command
       (...)
        run_command_1
         target_create_inferior
         proceed
 prints ("gdb") before exiting.

later, when inferior exits, the mi_exec_async_cli_cmd_continuation is called,
which prints that part:
> > 999*stopped,reason="exited-normally"
> > (gdb)

Here's a bit of current code:

enum mi_cmd_result
mi_execute_async_cli_command (char *mi, char *args, int from_tty)
{
  struct cleanup *old_cleanups;
  char *run;
  char *async_args;

  if (target_can_async_p ())
    {
      async_args = (char *) xmalloc (strlen (args) + 2);
      make_exec_cleanup (free, async_args);
      strcpy (async_args, args);
      strcat (async_args, "&");
      run = xstrprintf ("%s %s", mi, async_args);
      make_exec_cleanup (free, run);
      add_continuation (mi_exec_async_cli_cmd_continuation, NULL);
      old_cleanups = NULL;
    }
  else
    {
      run = xstrprintf ("%s %s", mi, args);
      old_cleanups = make_cleanup (xfree, run);
    }

  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);  <<<<< sync mode
                                                        prints it early.
      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);  <<<<< async mode
                                                   defers the "(gdb)" printing
    }

  execute_command ( /*ui */ run, 0 /*from_tty */ );

  (...)
}

So, -exec-run, in async mode, is turned into CLI's "run &", which ends
up in run_command_1.  At the end of it, after calling target_create_inferior
and friends, we do proceed.  So at this point the inferior as already started
running, and we haven't printed "(gdb)" yet.  We'll only print *after*
creating the inferior and proceed'ing.  There you have the difference to sync
mode.  It's really a timing issue, and that's why I can't reproduce -- it
is timing/host sensitive.  So this means this problem isn't related to my
patch, but it's a general async issue, that may be visible too in
"target async" connected to a gdbserver for example.  Although
since we're running over a slower link there, nobody was probably seeing
it.  I don't know enough MI to say if this is according to the spec
or not, but it feels like a testsuite deficiency, is it not?

-- 
Pedro Alves