[commit] inferior.h (enum stop_kind): Improve comment.

[Doug Evans]

Hi.

While working on fixing pr 14236 I found this comment
which wasn't as clear as it could be.

What does "It" refer to in "It is also used after attach, ..." ?

Reworded thusly.

2014-03-30  Doug Evans  <xdje42@gmail.com>

	* inferior.h (enum stop_kind): Improve comment.

diff --git a/gdb/inferior.h b/gdb/inferior.h
index 64a78ce..f8d358d 100644
--- a/gdb/inferior.h
+++ b/gdb/inferior.h
@@ -305,20 +305,20 @@ enum step_over_calls_kind
    setting up a remote connection; it is like STOP_QUIETLY_NO_SIGSTOP
    except that there is no need to hide a signal.  */
 
-/* It is also used after attach, due to attaching to a process.  This
-   is a bit trickier.  When doing an attach, the kernel stops the
-   debuggee with a SIGSTOP.  On newer GNU/Linux kernels (>= 2.5.61)
-   the handling of SIGSTOP for a ptraced process has changed.  Earlier
-   versions of the kernel would ignore these SIGSTOPs, while now
-   SIGSTOP is treated like any other signal, i.e. it is not muffled.
-   
+/* STOP_QUIETLY_NO_SIGSTOP is used to handle a tricky situation with attach.
+   When doing an attach, the kernel stops the debuggee with a SIGSTOP.
+   On newer GNU/Linux kernels (>= 2.5.61) the handling of SIGSTOP for
+   a ptraced process has changed.  Earlier versions of the kernel
+   would ignore these SIGSTOPs, while now SIGSTOP is treated like any
+   other signal, i.e. it is not muffled.
+
    If the gdb user does a 'continue' after the 'attach', gdb passes
    the global variable stop_signal (which stores the signal from the
    attach, SIGSTOP) to the ptrace(PTRACE_CONT,...)  call.  This is
    problematic, because the kernel doesn't ignore such SIGSTOP
    now.  I.e. it is reported back to gdb, which in turn presents it
    back to the user.
- 
+
    To avoid the problem, we use STOP_QUIETLY_NO_SIGSTOP, which allows
    gdb to clear the value of stop_signal after the attach, so that it
    is not passed back down to the kernel.  */