From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28823 invoked by alias); 30 Aug 2006 21:34:38 -0000 Received: (qmail 28814 invoked by uid 22791); 30 Aug 2006 21:34:38 -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; Wed, 30 Aug 2006 21:34:35 +0000 Received: from kahikatea.snap.net.nz (p202-124-124-250.snap.net.nz [202.124.124.250]) by viper.snap.net.nz (Postfix) with ESMTP id 14F297B82F2; Thu, 31 Aug 2006 09:34:31 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 27934BE447; Thu, 31 Aug 2006 09:32:20 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17654.994.815362.897653@kahikatea.snap.net.nz> Date: Wed, 30 Aug 2006 21:34:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? In-Reply-To: <20060830040113.GA8257@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> X-Mailer: VM 7.19 under Emacs 22.0.50.7 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/msg00256.txt.bz2 > 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. > 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. > > 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? -- Nick http://www.inet.net.nz/~nickrob New files: gdb/PROBLEMS.async gdb/README.async gdb/TODO.async gdb/async-nat-inferior.c gdb/async-nat-inferior.h gdb/async-nat-sigthread.c gdb/async-nat-sigthread.h Makefile.in | 13 gdb-mi.el | 2129 ++++++++++++++++++++++++-- gdb/ChangeLog | 3645 +-------------------------------------------- gdb/cli-out.c | 12 gdb/cli-out.h | 1 gdb/cli/cli-interp.c | 83 - gdb/config/i386/nm-linux.h | 3 gdb/defs.h | 11 gdb/event-loop.c | 72 gdb/event-loop.h | 9 gdb/event-top.c | 93 + gdb/event-top.h | 2 gdb/exec.c | 52 gdb/i386-linux-nat.c | 21 gdb/inf-child.c | 1 gdb/inf-loop.c | 46 gdb/inf-ptrace.c | 38 gdb/infcmd.c | 9 gdb/infrun.c | 26 gdb/interps.c | 40 gdb/interps.h | 3 gdb/linux-nat.c | 747 ++++----- gdb/linux-thread-db.c | 4 gdb/main.c | 13 gdb/mi/mi-interp.c | 82 - gdb/mi/mi-main.c | 371 ++++ gdb/mi/mi-main.h | 11 gdb/remote.c | 12 gdb/target.c | 31 gdb/target.h | 16 gdb/top.c | 25 gdb/tui/tui-hooks.c | 4 gdb/version.in | 2 gdb/wrapper.h | 2 linux.mh | 7 35 files changed, 3494 insertions(+), 4142 deletions(-)