X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=BUGS;h=0cb99ae63de3721d119541d9d7aade9b5525b11c;hp=57a538438e2ea9909fec7de79d148b87bf236562;hb=bbebfd9e134ec84a29dd68bc3661ead57435a4c3;hpb=f1f0d5e2d5b0964f87e5fc89da72f14aca024491

diff --git a/BUGS b/BUGS
index 57a538438e..0cb99ae63d 100644
--- a/BUGS
+++ b/BUGS
@@ -1,3 +1,4 @@
+// This file is part of the Doyxgen Developer Manual
 /** @page bugs Bug Reporting
 
 Please report bugs by subscribing to the OpenOCD mailing list and
@@ -5,33 +6,54 @@ posting a message with your report:
 
 	openocd-development@lists.berlios.de
 
-To minimize work for OpenOCD developers, you can include
-all the information below.  If you feel that some of the
-items below are unnecessary for a clear bug report, you
-leave them out.
+To minimize work for OpenOCD developers, you should try to include
+all of the information listed below.  If you feel that some of the
+items below are unnecessary for a clear bug report, you may leave
+them out; likewise, feel free to include additional information
+that may be important.
 
 - Target PCB/board description
-- Config scripts
+- Configuration scripts
 - OpenOCD command line
 - List of commands issued or GDB operations performed
 - Expected result
 - Actual result
-- Logs using @c debug_level 3 (e.g. add '-d 3' to the command line)
-- If this is a regression, include logs for working and broken version
-- If this is a regression, please find out the precise version that
-  caused the regression.  This can be done via a binary search; For
-  example: if testing version 550 works but 600 fail, then try 575, etc.
+- Logs using <code>debug_level 3</code> (or with '-d 3' on the command line)
+- If the report is for a regression:
+  - Include logs for both working and broken versions.
+  - Find the precise version that caused the regression by binary search.
+    You can use "git bisect" to expedite this binary search:  
+    http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
 
-- If OpenOCD is crashing, you can use GDB to get a trace:@par
+If possible, please develop and attach a patch that helps to expose or
+solve the reported problem.  See the PATCHES file for more information
+for that process.
+
+Attach all files directly to your posting.  The mailing list knows to
+transform attachments to links, but attachments must be less than 300KB
+in total.
+
+@section bugscrashdump Obtaining Crash Backtraces
+
+If OpenOCD is crashing, there are two very effective things you can do to
+improve your chances of getting help on the development mailing list. 
+
+Try to reproduce the problem using the dummy JTAG interface to allow other developers to replicate
+your problem robustly and use GDB to get a trace:@par
 @code
+% OPENOCDSRC/configure --enable-dummy ...
+% openocd -f interface/dummy.cfg -f target/xxx.cfg
+=> SEGFAULT
 % gdb --args openocd ....
 (gdb) run
 (gdb) bt
 => here a stack trace is dumped.
 @endcode
 
-- To run or debug the in-tree executable (not recommended), you must
-  use libtool to set up the correct shared library paths:
+@section bugsintreedebug Running and Debugging In-Tree
+
+To run or debug the in-tree executable (not recommended), you must
+use libtool to set up the correct shared library paths:
 @code
   libtool gdb --args openocd ....
 @endcode
@@ -39,9 +61,6 @@ or the more pedantic (and forward-compatible):
 @code
   libtool --mode=execute gdb --args openocd ....
 @endcode
-- Attach files directly to the posting.  The mailing list knows to
-transform attachments to links so you will not be bloating anyones mail
-box.  Please keep attachments to less than 100KB.
 
  */
 /** @file