From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22953 invoked by alias); 15 Oct 2014 14:31:04 -0000 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 Received: (qmail 22938 invoked by uid 89); 15 Oct 2014 14:31:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout26.012.net.il Received: from mtaout26.012.net.il (HELO mtaout26.012.net.il) (80.179.55.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Oct 2014 14:31:01 +0000 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NDH00700P3J0V00@mtaout26.012.net.il> for gdb-patches@sourceware.org; Wed, 15 Oct 2014 17:29:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDH004OXPKQYZ20@mtaout26.012.net.il>; Wed, 15 Oct 2014 17:29:14 +0300 (IDT) Date: Wed, 15 Oct 2014 14:31:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] stepi/nexti: skip signal handler if "handle nostop" signal arrives In-reply-to: <543E7961.5090002@redhat.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <838ukh5rry.fsf@gnu.org> References: <1413308910-30423-1-git-send-email-palves@redhat.com> <83ppdu5wx7.fsf@gnu.org> <543D7044.2000703@redhat.com> <83oate5uec.fsf@gnu.org> <543E7961.5090002@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00396.txt.bz2 > Date: Wed, 15 Oct 2014 14:40:49 +0100 > From: Pedro Alves > CC: gdb-patches@sourceware.org > > On 10/14/2014 08:22 PM, Eli Zaretskii wrote: > >> Date: Tue, 14 Oct 2014 19:49:40 +0100 > >> From: Pedro Alves > > > I think this text mixes 2 different things: (1) how the signal > > handling affects whether the signal gets to the program or not, and is > > it announced or not; and (2) the fine details of when the signal > > becomes "known" to the program and how stepping commands affect and > > are affected by that. > > > > It might be the simplest to separate the two issues, and describe each > > one on its own. > > I'll give that a try. Thanks. Let me know if I can help. > >> No, we intercept the signal before the program sees it. See above. > > > > But you wrote "the program stops for a signal". "The program stops" > > means (or at least could be interpreted as meaning) the signal was > > already seen by the program, and the program then stopped. > > > > See how this is confusing? > > I don't see how one would be confused, as the paragraph just above > says "When a signal stops your program", and I feel that the that > wording I chose follows naturally from that. As long as we didn't try to talk about fine details that happen at that time, it was okay. > I'll come up with a new version once I have a chance. Thanks in advance.