This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Async mode fixes.
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 8 Mar 2008 11:18:47 +1300
- Subject: Re: [RFA] Async mode fixes.
- References: <email@example.com>
> Presently, gdb's async mode is not very healthy, as follows:
> # of expected passes 10129
> # of unexpected failures 537
> # of unexpected successes 2
> # of expected failures 40
> # of known failures 48
> # of unresolved testcases 301
> # of untested testcases 10
> # of unsupported tests 63
> The attached patch improves that, bringing the results to:
> # of expected passes 10722
> # of unexpected failures 39
> # of unexpected successes 2
> # of expected failures 41
> # of known failures 51
> # of untested testcases 11
> # of unsupported tests 64
> where only few failures are actually specific to async mode. There
> are no regressions in non-async mode, on x86.
Like my patch, IMO this one looks a bit like a dog's breakfast. It's got some
good ideas, though, and has certainly increased my understanding of the
asynchronous code. Perhaps a combination of the two patches would create
It may reduce the failures, but I suspect that's partly because it's not really
running asynchronously. I don't understand how it really could without adding
another file handler for inferior events. That doesn't mean it can't, just
that I don't understand how it could.
> The patch has comments whenever appropriate, but some points need explicit
> To recap, current gdb, when operating with async-enabled target, allows
> two modes for all commands that run target. The fully async mode, requested
> by adding "&" to the command (say, "next &"), makes the target run, gives
> you a prompt and allows you to type further commands. If no "&" is added,
> then a sync execution is simulated -- whereby the prompt is suppressed
> and GDB does not handle any events on stdin. It is my understanding that
> we cannot kill this simulated sync mode because for console GDB,
> simulated sync mode is the only way we can allow the debugged program to
> read from stdin.
I think sync mode is also needed for command files. Also if you look at
top.c, only a few commands, e.g. pwd, can execute while the target is running.
> (I haven't checked if the interaction with debugged program
> indeed works, with Nick's linux async patch). This simulated sync mode
> is implemented by the sync_execution variable, and the
> async_enable_stdin and async_enable_stdout functions.
> This issue of simulate sync is not relevant to MI -- for MI, gdb stdin
> is generally a pipe, not a terminal, used only for reading
> commands from frontend and gdb has no way to route input to the application.
Emacs uses a tty for MI when one is available.
> Another important detail of async mode are continuations -- when we resume
> the target, we setup a function to be called when the target eventually
> stops. The relevant functions are add_continuation and do_all_continuations.
There's another continuation in the mi directory:
else if (target_can_async_p ())
add_continuation (mi_interpreter_exec_continuation, NULL);
You don't appear to have changed that. This is where I have issue with the
current `async' mode: it doesn't appear to use this continuation.
> The important problems with the current code are:
> 1. For MI mode, when we call a CLI command, in mi_cmd_interpreter_exec,
> we set sync_execution to 1 and then set it back to 0. This is just bogus --
> setting that variable without also disabling stdin bring the entire
> system in half-consistent state. Further, if the CLI command throws
> an exception, we fail to restore sync_execution. I just removed that code.
I think that _may_ be there because mi_cmd_interpreter_exec can process more
than one CLI command at a time:
-interpreter-exec console pwd dir
~"Working directory /home/nickrob.\n"
~"Source directories searched: $cdir:$cwd\n"
Perhaps that should be changed to just allow one command.