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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 14 Oct 2014 19:49:40 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches@sourceware.org
> 
> >> +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.

I was talking about the "pass" part, not about "nostop".

> 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.

Sorry, I'm still in the woods.

> 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.

I think this just muddies the water, sorry.

> 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.

This is also confusing.

>  +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.

I think this text mixes 2 different things: (1) how the signal
handling affects whether the signal gets to the program or not, and is
it announced or not; and (2) the fine details of when the signal
becomes "known" to the program and how stepping commands affect and
are affected by that.

It might be the simplest to separate the two issues, and describe each
one on its own.

> >> +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.

But you wrote "the program stops for a signal".  "The program stops"
means (or at least could be interpreted as meaning) the signal was
already seen by the program, and the program then stopped.

See how this is confusing?

If you want to describe the fine details of signal handling by GDB,
you need to tell more, and be very careful with your wording.

> > So the fact
> > that stepping commands continue there is a no-brainer, right?  Or a I
> > again confused?
> 
> The latter.  :-)

Then our readers will be even more confused.