This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] stepi/nexti: skip signal handler if "handle nostop" signal arrives
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 27 Oct 2014 21:58:44 +0200
- Subject: Re: [PATCH] stepi/nexti: skip signal handler if "handle nostop" signal arrives
- Authentication-results: sourceware.org; auth=none
- References: <1413308910-30423-1-git-send-email-palves at redhat dot com> <83ppdu5wx7 dot fsf at gnu dot org> <543D7044 dot 2000703 at redhat dot com> <83oate5uec dot fsf at gnu dot org> <543E7961 dot 5090002 at redhat dot com> <838ukh5rry dot fsf at gnu dot org> <544BAD08 dot 1050601 at redhat dot com> <83tx2p2z12 dot fsf at gnu dot org> <544EA096 dot 5050803 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Mon, 27 Oct 2014 19:44:22 +0000
> From: Pedro Alves <palves@redhat.com>
> 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.