From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1116 invoked by alias); 27 Oct 2014 17:39:08 -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 1106 invoked by uid 89); 27 Oct 2014 17:39:08 -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,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout21.012.net.il Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Oct 2014 17:39:02 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NE400D005Z2BM00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Mon, 27 Oct 2014 19:38:59 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE400D436CY84A0@a-mtaout21.012.net.il>; Mon, 27 Oct 2014 19:38:59 +0200 (IST) Date: Mon, 27 Oct 2014 17:39:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] stepi/nexti: skip signal handler if "handle nostop" signal arrives In-reply-to: <544BAD08.1050601@redhat.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83tx2p2z12.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> <838ukh5rry.fsf@gnu.org> <544BAD08.1050601@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00740.txt.bz2 > Date: Sat, 25 Oct 2014 15:00:40 +0100 > From: Pedro Alves > CC: gdb-patches@sourceware.org > > >>> 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. > > Alright, here's a new, expanded version. > > Let me know what you think. Thanks, this is a huge improvement. I have only a couple of minor stylistic suggestions: > +@cindex stepping and signal handlers > +@anchor{stepping and signal handlers} > + > +@value{GDBN} optimizes for stepping the mainline code. If a signal > +that has @code{handle nostop} and @code{handle pass} set arrives while > +a stepping command (e.g., @code{stepi}, @code{step}, @code{next}) is > +in progress, @value{GDBN} lets the signal handler run and then resumes > +stepping the mainline code once the signal handler returns. In other > +words, @value{GDBN} steps over the signal handler. If the signal has > +@code{handle noprint} set, then you won't even hear about it. This > +prevents signals that you've specified as not interesting (with I would suggest to use a semi-colon, not a period, before the last "This". That's because the last sentence is logically an immediate continuation of the one before it. By putting a full stop between them we create a potential for misunderstanding to what "this" refers, since the previous text described 2 different situations. Using a semi-colon removes that danger. For the same reason, it might be better to make "If the signal has 'handle noprint' ..." start a new paragraph. > +@cindex stepping into signal handlers > +@anchor{stepping into signal handlers} I would remove this @cindex entry: it doesn't add anything useful to the previous one, and will likely point to the same page. > +If the program was stopped for a signal (that is, stopped before the > +program sees it), due to @code{handle stop} being set, and > +@code{handle pass} is in effect for that signal too, and your program > +handles the signal, a stepping command such as for example > +@code{stepi} or @code{step} steps @emph{into} the signal's handler (if > +the target supports it). This is a mouthful, not in the least because of excessive use of past tense. How about this variant instead: If you set @code{handle stop} for a signal, @value{GDBN} stops your program and announces the signal when it arrives, before the program sees it. If you also set @code{handle pass} for that signal, and your program sets up a handler for it, then issuing a stepping command, such as @code{step} or @code{stepi}, when your program is stopped due to the signal will step @emph{into} the signal handler (if the target supports that). > +Likewise, if the @code{queue-signal} command was used to queue a > +signal to be delivered to the current thread when execution of the Please reword in active tens ("... if you use the @code{queue-signal} command to queue ..."). > +thread resumes (@pxref{Signaling, ,Giving your Program a Signal}), > +then a stepping command steps into the signal's handler. Not sure I understand the sequence here. First, I queue-signal, then the signal is delivered and the thread stops, and _then_ I issue si? I guess the "when execution of the thread resumes" confused me. Thanks.