From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32001 invoked by alias); 30 Aug 2006 21:43:03 -0000 Received: (qmail 31993 invoked by uid 22791); 30 Aug 2006 21:43:03 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 30 Aug 2006 21:42:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GIXpp-0001V8-CS; Wed, 30 Aug 2006 17:42:57 -0400 Date: Wed, 30 Aug 2006 21:43:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? Message-ID: <20060830214257.GA5397@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb@sources.redhat.com 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17654.994.815362.897653@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.11+cvs20060403 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-08/txt/msg00257.txt.bz2 On Thu, Aug 31, 2006 at 09:32:18AM +1200, Nick Roberts wrote: > > Just generate the diff between your mergepoint and branch, and then > > pipe it to diffstat, assuming you've got it installed. > > Doing: > > cvs diff -r nickrob-async-20060828-mergepoint gdb | diffstat > > from the src directory gives the output below. Not too bad. > > Well, I meant from an internals perspective - like, a patch just > > summarizing the interface changes, if the whole patch is too big to > > post at once. > > Instead of GDB waiting for the enferior to stop directly, it creates a signal > thread to do that. This means that the main thread can continue to process the > event loop. When the inferior does stop, the signal thread writes to a file > which GDB detects through handle_file_event in the event loop. It then calls > inferior_event_handler. OK, this is easily mimicable without threads, at least on GNU/Linux. On Cygwin/Windows I imagine we'd want to use threads, but the tradeoffs there are somewhat different :-) > > > Also it still uses pthreads. You said previously that it should be done > > > in one process and, following a remark from Jim Ingham, that ptrace is > > > non-blocking. AFAICS the problem is that wait *is* blocking and I can't > > > see of a way to deal with that without using another thread. > > > > Ah, but wait is non-blocking. You have to (A) use WNOHANG, and (B) be > > careful to handle asynchronous SIGCHLD events. It's not especially > > difficult, I don't think, but the async event loop in gdb has always > > confused me; we'll have to figure out how to gather up sigchld/wait > > events. > > The manpage just says: > > WNOHANG > return immediately if no child has exited. > > but what value does it return with? Does GDB ignore SIGCHLD events so it > can detect state changes through wait? If that's all it says I recommend a better man page :-) waitpid(): on success, returns the process ID of the child whose state has changed; on error, -1 is returned; if WNOHANG was specified and no child(ren) specified by pid has yet changed state, then 0 is returned. Different ports of GDB treat SIGCHLD differently. linux-nat.c, for instance, blocks it so that it can use sigsuspend. Instead, we would have to register handlers for sigchld events somehow (probably using the same infrastructure used for SIGINT to quit operations). I can work on this, though not right away. -- Daniel Jacobowitz CodeSourcery