From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18163 invoked by alias); 14 Oct 2014 18:56:20 -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 18146 invoked by uid 89); 14 Oct 2014 18:56:20 -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; Tue, 14 Oct 2014 18:56:19 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9EIuHPM012901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 14 Oct 2014 14:56:17 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9EIuFlB015457; Tue, 14 Oct 2014 14:56:16 -0400 Message-ID: <543D71CF.9070402@redhat.com> Date: Tue, 14 Oct 2014 18:56: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> In-Reply-To: <543D7044.2000703@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00362.txt.bz2 On 10/14/2014 07:49 PM, Pedro Alves wrote: > On 10/14/2014 07:27 PM, Eli Zaretskii wrote: >>> From: Pedro Alves >>> Date: Tue, 14 Oct 2014 18:48:30 +0100 >>> >>> --- a/gdb/doc/gdb.texinfo >>> +++ b/gdb/doc/gdb.texinfo >>> @@ -5526,6 +5526,11 @@ Their full names are: >>> @value{GDBN} should not stop your program when this signal happens. It may >>> still print a message telling you that the signal has come in. >>> >>> +If this signal arrives while a stepping command (e.g., @code{step}) is >>> +in progress, the signal's handler is skipped (though still executed if >>> +@code{pass} is in effect; see below). @value{GDBN} will still stop >>> +your program if the handler hits a breakpoint. >> >> This description is confusing. For starters, it only mentions some of >> the possible setting of signal handling, and keeps silence about the >> rest. Either we should describe what happens with all of them, one by >> one, or (better) says something that will explain how we handle them >> all, at once. > > This paragraph is added to the "nostop" entry of the table. It directly > relates to the entry in question: > > Specifically, it's a preemptive response to the question I'd have if > I read the paragraph just above, which talks about the signal but > leaves the question of the signal handler open: > > @table @code > @item nostop > @value{GDBN} should not stop your program when this signal happens. It may > still print a message telling you that the signal has come in. > > If this signal arrives while a stepping command (e.g., @code{step}) is > in progress, the signal's handler is skipped (though still executed if > @code{pass} is in effect; see below). @value{GDBN} will still stop > your program if the handler hits a breakpoint. > > I could extend the "stop" item: > > @item stop > @value{GDBN} should stop your program when this signal happens. This implies > the @code{print} keyword as well. > > Like: > > + The signal is not visible to the program until you continue. > > WDYT? > > > This is also said further below, after the table (and is what the > "see below" referred to): > > When a signal stops your program, the signal is not visible to the > program until you > continue. Your program sees the signal then, if @code{pass} is in > effect for the signal in question @emph{at that time}. In other words, > after @value{GDBN} reports a signal, you can use the @code{handle} > command with @code{pass} or @code{nopass} to control whether your > program sees that signal when you continue. > > +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). > > The '+' lines are what I'm adding. Would this tweak below make it clearer? The contrast against stepping mainline code is really the point I'm trying to make: 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, instead of stepping the mainline code, if the target supports it. Thanks, Pedro Alves