Re: linux native async mode support

[Pedro Alves <pedro at codesourcery dot com>]

Sorry, forgot to post the sync run without the failure for comparision.

A Wednesday 19 March 2008 23:18:45, Pedro Alves wrote:
> 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)
>

In sync mode:
999-exec-continue
999^running
(gdb) << immediatelly after "^running".  Keep reading.
Hello, World!callme
callme
999*stopped,reason="exited-normally"
(gdb)


> 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