From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14744 invoked by alias); 18 Jun 2007 11:32:20 -0000 Received: (qmail 14734 invoked by uid 22791); 18 Jun 2007 11:32:19 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Jun 2007 11:32:17 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id ED32F982E4; Mon, 18 Jun 2007 11:32:15 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B75A2982E3; Mon, 18 Jun 2007 11:32:15 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I0FTC-0000k9-QF; Mon, 18 Jun 2007 07:32:30 -0400 Date: Mon, 18 Jun 2007 11:32:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: async patch (no. 4) Message-ID: <20070618113230.GA2778@caradoc.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17720.29835.230422.776965@kahikatea.snap.net.nz> <20070112183120.GB30005@nevyn.them.org> <17832.2690.298735.867020@kahikatea.snap.net.nz> <20070112230333.GA7039@nevyn.them.org> <18036.65200.916738.36790@kahikatea.snap.net.nz> <20070617152125.GA17563@caradoc.them.org> <18037.40606.95329.378825@kahikatea.snap.net.nz> <20070618024611.GA12587@caradoc.them.org> <18038.4452.524773.721616@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18038.4452.524773.721616@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-06/txt/msg00333.txt.bz2 On Mon, Jun 18, 2007 at 05:00:20PM +1200, Nick Roberts wrote: > Sure, but to be fair I think this is the first time you have asked them. Sure. Like I said, the patch is hard to review. I think that each of the bits I asked a question about is, logically, a separate change to GDB. More or less. > 1) what does async_signal_hook do > > Firstly this patch only currently works for Linux. That is because I don't > know enough about other OSes and ISTR that you said others could extend > easily it to them later. For Linux, async_signal_hook is initialised to > linux_nat_signal_hook in _initialize_linux_nat. It is called (with > different arguments) immediately before and after calls to select (or poll, > if appropriate) and only if gdb is invoked with --async (event_loop_p != 0). > > On the first call, linux_nat_signal_hook sets up a handler, > async_sigchld_handler, for SIGCHLD, that writes the return value of waitpid > to the file descriptor that linux_nat_fetch_event reads from. > linux_nat_fetch_event is called instead of my_waitpid with an asynchronous > target in linux_nat_wait. On the second call linux_nat_signal_hook > restores the old signal mask. > > I'll try to answer the other questions in due course, but I'd like to hear if > you think I'm making sense trying to answer this one first. Yes, that makes sense - thank you, and this gives me a sense of making progress on the async patch :-) It does explain what the hook is for, although actually the hook is the wrong approach. If this belongs to the native target, then it should be target_async_signal_hook (1) and go through the target vector. On the other hand, if the remote target is going to want to use the same technique on GNU/Linux (i.e. if it depends on the host) then maybe it belongs somewhere else and not as a hook at all. Either utils.c or posix-hdep.c depending how different it is going to be on multiple platforms. More broadly, we have a couple of different ways for providing host-specific and target-specific code so a new global function pointer should be avoided. -- Daniel Jacobowitz CodeSourcery