Re: [PATCH] stepi/nexti: skip signal handler if "handle nostop" signal arrives

[Eli Zaretskii <eliz@gnu.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.