From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6179 invoked by alias); 14 Jun 2008 19:22:27 -0000 Received: (qmail 6167 invoked by uid 22791); 14 Jun 2008 19:22:26 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout4.012.net.il (HELO mtaout4.012.net.il) (84.95.2.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Jun 2008 19:22:06 +0000 Received: from HOME-C4E4A596F7 ([84.228.242.237]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K2G00K5CX5VTGE3@i_mtaout4.012.net.il> for gdb-patches@sources.redhat.com; Sat, 14 Jun 2008 22:37:07 +0300 (IDT) Date: Sat, 14 Jun 2008 19:51:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] Add comments to linux-nat.c In-reply-to: <200806141829.05646.vladimir@codesourcery.com> X-012-Sender: halo1@inter.net.il To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <200806141829.05646.vladimir@codesourcery.com> 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-06/txt/msg00267.txt.bz2 > From: Vladimir Prus > Date: Sat, 14 Jun 2008 18:29:05 +0400 > > > With the introduction of async mode, linux-nat.c became even more complex that it > was, and it became apparent that some high-level comments are needed. So, I've grabbed > Pedro and Dan on IRC and extracted the knowledge from their heads into a text file. > Here's the result. OK? Thanks. I don't know anything about the subject matter, but I spotted a few typos in the text: > +threads. (2.4 has the __WALL flag). So, it we use blocking waitpid, we might ^^ "if" > +sigsuspend. First, we use non-blocking waitpid to get if there's event "to get if there's event" is not quite right, you probably wanted to say "to find out if there's event". > +in main debugged process and in cloned processes. child processes. As soon ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Something's wrong here. > +The main design point is that every time GDB is outside linux-nat.c, we have a > +SIGCLD handler installed that is called when something happens to the target ^^^^^^ SIGCLD or SIGCHLD? > +Those waitpid calls, while blocking, are guarantied to always always have ^^^^^^^^^^^^^ "always" twice. > +of the pipe amoung the sources. When event loop starts to process the event ^^^^^^ "among" > +us. Technically, it would be possible to add new events to the local queue but > +it's about the same amount of work than blocking SIGCHLD. ^^^^^^^^^^^^^^^^^^^^^ "as blocking SIGCHLD" > +enter/leave linux-nat.c is somewhat ugly. Unfortunately, GDB event loop is > +home-grown is incapable to wait on any queue. Something's wrong in "is home-grown is incapable". > +tkill'd. But we never let the SIGSTOP deliver; we always intercept and cancel ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "never let SIGSTOP be delivered".