Re: linux native async mode support

Pedro Alves
2008-03-19T23:26:49Z

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