From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13432 invoked by alias); 15 Oct 2014 13:40:55 -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 13415 invoked by uid 89); 15 Oct 2014 13:40:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 15 Oct 2014 13:40:54 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FDepih003375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 09:40:51 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FDen3G006922; Wed, 15 Oct 2014 09:40:50 -0400 Message-ID: <543E7961.5090002@redhat.com> Date: Wed, 15 Oct 2014 13:40:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org Subject: Re: [PATCH] stepi/nexti: skip signal handler if "handle nostop" signal arrives References: <1413308910-30423-1-git-send-email-palves@redhat.com> <83ppdu5wx7.fsf@gnu.org> <543D7044.2000703@redhat.com> <83oate5uec.fsf@gnu.org> In-Reply-To: <83oate5uec.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00390.txt.bz2 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. > >>>> +If a stepping command is issued after the program stops for a signal, >>>> +and @code{pass} is in effect for that signal, @value{GDBN} steps into >>>> +the signal's handler (if the target supports it). >>> >>> Again, this left me wondering. E.g., if the program stops for a >>> signal, then we are already in the signal handler, no? >> >> 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. But, anyway, I'll try to clarify this. >>> So the fact >>> that stepping commands continue there is a no-brainer, right? Or a I >>> again confused? >> >> The latter. :-) > > Then our readers will be even more confused. Eheh, so true... I often say that myself. I'll come up with a new version once I have a chance. Thanks, Pedro Alves