From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17053 invoked by alias); 26 Sep 2006 23:40:40 -0000 Received: (qmail 17044 invoked by uid 22791); 26 Sep 2006 23:40: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; Tue, 26 Sep 2006 23:40:37 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-172.snap.net.nz [202.124.125.172]) by viper.snap.net.nz (Postfix) with ESMTP id A794A7B995F; Wed, 27 Sep 2006 11:40:32 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id BE77BBE436; Wed, 27 Sep 2006 11:37:49 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17689.47563.949450.420418@kahikatea.snap.net.nz> Date: Tue, 26 Sep 2006 23:40:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? In-Reply-To: <20060926222406.GA30535@nevyn.them.org> References: <17652.63229.637451.185345@kahikatea.snap.net.nz> <20060830023335.GA6377@nevyn.them.org> <17653.930.196634.143646@kahikatea.snap.net.nz> <20060830040113.GA8257@nevyn.them.org> <17654.994.815362.897653@kahikatea.snap.net.nz> <20060830214257.GA5397@nevyn.them.org> <17688.59135.24869.397517@kahikatea.snap.net.nz> <20060926123757.GA9879@nevyn.them.org> <17689.42274.369631.215081@kahikatea.snap.net.nz> <20060926222406.GA30535@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.50.21 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00159.txt.bz2 > Right - but you don't need to put the actual data (e.g. the PID and > status) through the fd. I guess it doesn't hurt, but it does make > things harder to debug. Instead, you can save them in memory, and > just push a byte through the fd - that will make it show up in select. OK, if that's simpler. > > > Moving the call to waitpid out of linux-nat.c, and to a target > > > independent file, is a mistake - presumably that's just how you got it > > > to work quickly? That's related to why it doesn't work for threads. > > > The vital line is "options ^= __WCLONE" in the loop in linux_nat_wait. > > > Without __WCLONE, you'll never see a wait status from a thread; with > > > it you'll never see a wait status from the main program. > > > > Perhaps I can use __WALL as a catch all. > > There's supposedly some supported kernel versions left where that > didn't work. Why can't you use the same code the existing support > uses? AFAICS the problem is one of timing. GDB uses the status information in linux_nat_wait but must detect that the status has changed in the event loop (gdb_wait_for_event). However linux_nat_wait makes many calls to waitpid (at least in the multi-threaded case). I am/was hoping that, for asynchronous operation, I only need to replace the first call to waitpid with another one, which I've called gdb_fetch_event, to read the status information which has already been waited on. That's probably a bit naive but I can't see how I can dart back and forth between gdb_wait_for_event and a single call to linux_nat_wait. > I'm sorry I haven't been able to pitch in and help with this. I > checked it out last week and started looking at it, but I'm buried > in work past my eyeballs right now. I'm just grateful for any help you can give me. -- Nick http://www.inet.net.nz/~nickrob