From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4688 invoked by alias); 27 Oct 2014 19:58:59 -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 4677 invoked by uid 89); 27 Oct 2014 19:58:58 -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: mtaout28.012.net.il Received: from mtaout28.012.net.il (HELO mtaout28.012.net.il) (80.179.55.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Oct 2014 19:58:56 +0000 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NE400800CQATK00@mtaout28.012.net.il> for gdb-patches@sourceware.org; Mon, 27 Oct 2014 21:56:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE4005XJCQIG920@mtaout28.012.net.il>; Mon, 27 Oct 2014 21:56:42 +0200 (IST) Date: Mon, 27 Oct 2014 19:58:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] stepi/nexti: skip signal handler if "handle nostop" signal arrives In-reply-to: <544EA096.5050803@redhat.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83oasx2sjv.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> <83tx2p2z12.fsf@gnu.org> <544EA096.5050803@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00745.txt.bz2 > Date: Mon, 27 Oct 2014 19:44:22 +0000 > From: Pedro Alves > CC: gdb-patches@sourceware.org > > So, perhaps this variant is clearer? > > @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. This prevents > signals that you've specified as not interesting (with @code{handle > nostop}) from changing the focus of debugging unexpectedly. Note that > the signal handler itself may still hit a breakpoint, stop for another > signal that has @code{handle stop} in effect, or for any other event > that normally results in stopping the stepping command sooner. Also > note that @value{GDBN} still informs you that the program received a > signal if @code{handle print} is set. Yes, this is OK. > >> +@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. > > I'd prefer to keep it, if you don't mind. The queue-signal reference wants > to point here directly, and I can imagine the text above expanding in > directions not relevant for that cross reference. Both entries use the same words, so why do we need both? There's one paragraph of only a dozen of text lines between them. > I'd like to have a place where I can point at when the topic of > wanting to debug a handler without knowing exactly which function > that is comes up. For pointing, you have the anchor; I didn't say to delete that. Index entries cannot point. In fact, some Info readers land you at the beginning of the node, not at the place where the entry was in Texinfo. > I'm now thinking that we can just remove that part, and use the rest of > your paragraph below: > > > 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). Fine with me. > >> +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. > > Sounds like you're thinking of "queue-signal" like "kill" from the shell, > but that's not how "queue-signal" works. "queue-signal" instead > passes the signal to the program immediately as if the thread had > _already_ stopped for the signal. GDB doesn't intercept > the signal anymore. How is this different from what I wrote? The program behaves as if the signal was delivered to it, right? > I've added a queue-signal example. Hopefully that makes things clearer. It does, thanks. > Let me know how this version looks. LGTM.