From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26525 invoked by alias); 15 Mar 2008 01:58:00 -0000 Received: (qmail 26517 invoked by uid 22791); 15 Mar 2008 01:57:59 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 15 Mar 2008 01:57:40 +0000 Received: (qmail 1077 invoked from network); 15 Mar 2008 01:57:39 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Mar 2008 01:57:39 -0000 From: Pedro Alves To: Nick Roberts Subject: Re: linux native async mode support Date: Sat, 15 Mar 2008 01:58:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sourceware.org References: <200803140810.22883.pedro@codesourcery.com> <18395.1471.637574.722785@kahikatea.snap.net.nz> In-Reply-To: <18395.1471.637574.722785@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803150157.47855.pedro@codesourcery.com> 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/msg00209.txt.bz2 A Friday 14 March 2008 23:09:51, Nick wrote: > Wow! :-) > It seems unfortunate that you had to move async_file_handler into > linux_nat.c as much of this seems generic and will presumably make it > harder to port the async mode to other platforms. I put it in inf-ptrace.c > (*) which creates problems if the target doesn't actually support async > mode. More recently I thought maybe not setting t->to_async_mask_value to > 1 in inf_ptrace_target might solve that. > On the contraire. Not assuming abstractions upfront allows us to enhance and test the linux port, without worrying about the other inf-ptrace.c clients breaking. We'll add the non-stop support soon, and that will need further tweaking. We can worry about abstractions and common code when someone wants to add async support to another target. I'd advise to hold on a bit until we stabilize this port a bit more. > Daniel talks about async mode being the default but I don't really > understand this. In order for Gdb to be able to accept input while the > inferior is running and possibly accepting it's own input, seems to require > separate terminals. This isn't a problem for a front end but, in general, > will be when Gdb is run from the command line. This is a confusion of terms. The async mode he was refering to, is the event loop code path, in which we (ideally) never block in wait_for_inferior. I'm sure you know most of this already, but let me repeat it for clarity. If the target supports async event loop mode, the user can still run the inferior in synchronous mode, with the usual commands, and gdb can put the inferior in the foreground. That's currently controlled by the sync_execution global variable. The sync_execution mode is implemented on top of the async/event loop code path, and can (ideally) be ignored by the target code (as long as it supports async/event loop mode). It is up to gdb common code to disable stdin to simulate synchronous execution, which enables passing the terminal to the inferior. From a users perpective, target in event loop mode with sync_execution set is the same as what we have had until now. In addition to that mode, by having the target in async/event loop mode, the user/frontend can use the background execution commands (run&, continue&, step&, etc.), which makes gdb accept input from the user/frontend while the inferior is running. This is essential for non-stop mode, which we'll be adding soon. In a nutshell, having the target in "async mode" has no drawbacks, only advantages. It's only that it isn't perfect yet. When we get to the point where the non-async code path is not needed anymore, we can drop a bunch of support code. That's doesn't seem likelly to happen anytime soon in the common code, but it can be done target by target. Linux native and target (extended-)remote are the first candidates. (I'll address the patch comments later) Thanks! -- Pedro Alves