From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2928 invoked by alias); 14 Mar 2008 23:10:41 -0000 Received: (qmail 2905 invoked by uid 22791); 14 Mar 2008 23:10:40 -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, 14 Mar 2008 23:09:58 +0000 Received: from kahikatea.snap.net.nz (48.62.255.123.dynamic.snap.net.nz [123.255.62.48]) by viper.snap.net.nz (Postfix) with ESMTP id 701E83DA7F8; Sat, 15 Mar 2008 12:09:55 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id A94CB8FC6D; Sat, 15 Mar 2008 12:09:52 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18395.1471.637574.722785@kahikatea.snap.net.nz> Date: Fri, 14 Mar 2008 23:10:00 -0000 To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: linux native async mode support In-Reply-To: <200803140810.22883.pedro@codesourcery.com> References: <200803140810.22883.pedro@codesourcery.com> X-Mailer: VM 7.19 under Emacs 23.0.60.39 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/msg00206.txt.bz2 > This patch adds linux native async mode support. Wow! This is an awesome patch especially as your previous changes seem to be for different parts of Gdb. I think my patch only really worked if only one SIGCHLD signal came in for each round trip in the event loop. I was starting to see that that the signal handler shouldn't be wrapped around select and that I would need to queue signals but I never began to understand all the waitpids in linux_nat_wait or how to get back to the event loop when all the SIGCHLD signals had been processed. I have some initial comments but bear in mind it's from a position of lesser understanding. I can see that I really need to up my game a bit! 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. (*) I copied this from Apple whose handler was in macosx-nat-inferior.c but their build is only for one architecture (maybe two now but source appears to be no longer available from their repository) --- + /* SIGCHLD handler for async mode. */ + async_action.sa_handler = async_sigchld_handler; + sigemptyset (&async_action.sa_mask); + async_action.sa_flags = SA_RESTART; + sigaddset (&async_action.sa_mask, SIGCHLD); I'm not sure that last line is necessary (I had it in my patch, I know) as the libc manual says: When a handler function is invoked on a signal, that signal is automatically blocked (in addition to any other signals that are already in the process's signal mask) during the time the handler is running. --- 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. -- Nick http://www.inet.net.nz/~nickrob