This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: linux native async mode support
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