From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14903 invoked by alias); 14 Oct 2014 18:49:47 -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 14894 invoked by uid 89); 14 Oct 2014 18:49:47 -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:49:46 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9EIngh0007263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 14 Oct 2014 14:49:43 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9EInef0004565; Tue, 14 Oct 2014 14:49:41 -0400 Message-ID: <543D7044.2000703@redhat.com> Date: Tue, 14 Oct 2014 18:49: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> In-Reply-To: <83ppdu5wx7.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00360.txt.bz2 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. > > Also, I believe the description of stepping should mention this > aspect, with a cross-reference to here. OK. > >> +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. > So the fact > that stepping commands continue there is a no-brainer, right? Or a I > again confused? The latter. :-) Thanks, Pedro Alves