From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14423 invoked by alias); 7 Mar 2008 22:19:27 -0000 Received: (qmail 14410 invoked by uid 22791); 7 Mar 2008 22:19:26 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Mar 2008 22:18:57 +0000 Received: from kahikatea.snap.net.nz (134.30.255.123.static.snap.net.nz [123.255.30.134]) by viper.snap.net.nz (Postfix) with ESMTP id F193A3DA7B1; Sat, 8 Mar 2008 11:18:49 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id C0D738FC6D; Sat, 8 Mar 2008 11:18:48 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18385.48967.964309.898509@kahikatea.snap.net.nz> Date: Fri, 07 Mar 2008 22:19:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Async mode fixes. In-Reply-To: <200803051027.29575.vladimir@codesourcery.com> References: <200803051027.29575.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.1.91.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00059.txt.bz2 > 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