cleanup a tad

diff --git a/winsup/cygwin/how-to-debug-cygwin.txt b/winsup/cygwin/how-to-debug-cygwin.txt
index 100e9ac3413ddda757c1dd31e4dc6a228eb2423d..2549565bfe385e7f546ad6c63ad068908a3c11a2 100644 (file)
--- a/winsup/cygwin/how-to-debug-cygwin.txt
+++ b/winsup/cygwin/how-to-debug-cygwin.txt
@@ -1,4 +1,4 @@
-Copyright 2001 Red Hat Inc., Egor Duda
+Copyright 2001, 2002 Red Hat Inc., Egor Duda
 
 So, your favorite program has crashed?  And did you say something about
 'stackdump'?  Or it just prints its output from left to right and
@@ -9,14 +9,17 @@ you can do something better than that.  You can debug the problem
 yourself, and even if you can't fix it, your analysis may be very
 helpful.  Here's the (incomplete) howto on cygwin debugging.
 
-1.  The first thing you'll need to do is to build cygwin1.dll and your
+1.  First things first
+
+    The first thing you'll need to do is to build cygwin1.dll and your
     crashed application from sources.  To debug them you'll need debug
     information, which is normally stripped from executables.  You probably
     also want to build a version of the dll with more debugging capabilities
     by reconfiguring your build directory, specifying the --enable-debugging
     option to configure.
 
-2. Create known-working cygwin debugging environment.
+2. Creating a known-working cygwin debugging environment
+
    - create a separate directory, say, c:\cygdeb, and put known-working
      cygwin1.dll and gdb.exe in it.
    - create a wrapper c:\cygdeb\debug_wrapper.cmd:
@@ -28,13 +31,15 @@ set CYGWIN_TESTING=1
 c:\cygdeb\gdb.exe -nw %1 %2
 ===================================
 
-3. Try to use cygwin's JIT debugging facility:
+3. Using cygwin's JIT debugging facility
+
    add 'error_start=c:\cygdeb\debug_wrapper.cmd' to CYGWIN environment
    variable. When some application encounters critical error, cygwin will stop
    it and execute debug_wrapper.cmd, which will run gdb and make it to attach to
    the crashed application.
 
-4. Strace.
+4. Strace
+
    You can run your program under 'strace' utility, described if user's manual.
    If you know where the problem approximately is, you can add a bunch of
    additional debug_printf()s in the source code and see what they print in
@@ -49,7 +54,8 @@ c:\cygdeb\gdb.exe -nw %1 %2
    starts does not inherit a cygwin environment.  It is equivalent to starting
    a program from the command prompt.
 
-5. Problems at early startup.
+5. Problems at early startup
+
    Sometimes, something crashes at the very early stages of application
    initialization, when JIT debugging facility is not yet active. Ok, there's
    another environment variable that may help. Create program_wrapper.cmd:
@@ -71,6 +77,8 @@ c:\some\path\bad_program.exe some parameters
    After that you can normally step through the code in cygwin1.dll and
    bad_program.exe
 
+6. More problems at early startup
+
    You can also set a CYGWIN_DEBUG variable to force the debugger to pop up
    only when a certain program is run:
 
@@ -84,7 +92,8 @@ set CYGWIN_DEBUG=cat.exe=gdb.exe
    Note that it bears repeating that both of the above options are *only*
    available when configuring cygwin with --enable-debugging.
 
-6. Heap corruption.
+7. Heap corruption
+
    If your program crashes at malloc() or free() or when it references some
    malloc()'ed memory, it looks like heap corruption. You can configure and
    build special version of cygwin1.dll which includes heap sanity checking.
@@ -92,7 +101,8 @@ set CYGWIN_DEBUG=cat.exe=gdb.exe
    however, that this version of dll is _very_ slow (10-100 times slower than
    normal), so use it only when absolutely necessary.
 
-7. Program dies when running under strace.
+8. Program dies when running under strace
+
    If your program crashes when you run it using strace but runs ok (or has a
    different problem) otherwise, then there may be a problem in one of the
    strace *_printf statements.  Usually this is caused by a change in arguments