Re: [RFA] Async mode fixes.

[Nick Roberts <nickrob@snap.net.nz>]

 > 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
something useful.

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
 > clarification.
 > 
 > 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"
^done
(gdb) 

Perhaps that should be changed to just allow one command.

> ...

-- 
Nick                                           http://www.inet.net.nz/~nickrob