etc/DEBUG: Improve instructions for debugging infinite loops.

etc/DEBUG

@@ -398,9 +398,13 @@ to start debugging.
 Don't assume Emacs is `hung'--it may instead be in an infinite loop.
 To find out which, make the problem happen under GDB and stop Emacs
 once it is not responding.  (If Emacs is using X Windows directly, you
-can stop Emacs by typing C-z at the GDB job.)  Then try stepping with
-`step'.  If Emacs is hung, the `step' command won't return.  If it is
-looping, `step' will return.
+can stop Emacs by typing C-z at the GDB job.  On MS-Windows, run Emacs
+as usual, and then attach GDB to it -- that will usually interrupt
+whatever Emacs is doing and let you perform the steps described
+below.)
+
+Then try stepping with `step'.  If Emacs is hung, the `step' command
+won't return.  If it is looping, `step' will return.
 
 If this shows Emacs is hung in a system call, stop it again and
 examine the arguments of the call.  If you report the bug, it is very
@@ -420,10 +424,11 @@ stepping, you will see where the loop starts and ends.  Also, examine
 the data being used in the loop and try to determine why the loop does
 not exit when it should.
 
-You can also trying sending Emacs SIGUSR2, which, if `debug-on-event'
-has its default value, will cause Emacs to attempt to break it out of
-its current loop and into the Lisp debugger.  This feature is useful
-when a C-level debugger is not conveniently available.
+On GNU and Unix systems, you can also trying sending Emacs SIGUSR2,
+which, if `debug-on-event' has its default value, will cause Emacs to
+attempt to break it out of its current loop and into the Lisp
+debugger.  This feature is useful when a C-level debugger is not
+conveniently available.
 
 ** If certain operations in Emacs are slower than they used to be, here
 is some advice for how to find out why.