aboutsummaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorPaul Fertser <fercerpav@gmail.com>2018-01-16 15:11:18 +0300
committerMatthias Welwarsky <matthias@welwarsky.de>2018-04-09 09:05:58 +0100
commit6e356cbfe27c1718d784f7aa36efb483a523fb64 (patch)
tree8406b1680b179823a38663a2e56c795e4686b06c /HACKING
parent70b15f989f09428a85d6e52d8a03dc902081eb01 (diff)
HACKING: document practices to improve code quality
Change-Id: I58a7d978b7d5bca3037c4535f06746b9f4411950 Signed-off-by: Paul Fertser <fercerpav@gmail.com> Reviewed-on: http://openocd.zylin.com/4343 Tested-by: jenkins
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING54
1 files changed, 50 insertions, 4 deletions
diff --git a/HACKING b/HACKING
index 0bea65a7..0d24957e 100644
--- a/HACKING
+++ b/HACKING
@@ -29,12 +29,58 @@ The procedure to create a patch is essentially:
- correct the patch and re-send it according to review feedback
Your patch (or commit) should be a "good patch": focus it on a single
-issue, and make it be easily reviewable. Don't make
+issue, and make it easily reviewable. Don't make
it so large that it's hard to review; split large
-patches into smaller ones. (That can also help
-track down bugs later on.) All patches should
+patches into smaller ones (this will also help
+to track down bugs later). All patches should
be "clean", which includes preserving the existing
-coding style and updating documentation as needed.
+coding style and updating documentation as needed. When adding a new
+command, the corresponding documentation should be added to
+@c doc/openocd.texi in the same commit. OpenOCD runs on both Little
+Endian and Big Endian hosts so the code can't count on specific byte
+ordering (in other words, must be endian-clean).
+
+There are several additional methods of improving the quality of your
+patch:
+
+- Runtime testing with Valgrind Memcheck
+
+ This helps to spot memory leaks, undefined behaviour due to
+ uninitialized data or wrong indexing, memory corruption, etc.
+
+- Clang Static Analyzer
+
+ Using this tool uncovers many different kinds of bugs in C code,
+ with problematic execution paths fully explained. It is a part of
+ standard Clang installation.
+
+ To generate a report, run this in the OpenOCD source directory:
+ @code
+ mkdir build-scanbuild; cd build-scanbuild
+ scan-build ../configure
+ scan-build make CFLAGS="-std=gnu99 -I. -I../../jimtcl"
+ @endcode
+
+- Runtime testing with sanitizers
+
+ Both GCC and LLVM/Clang include advanced instrumentation options to
+ detect undefined behaviour and many kinds of memory
+ errors. Available with @c -fsanitize=* command arguments.
+
+ Example usage:
+ @code
+ mkdir build-sanitizers; cd build-sanitizers
+ ../configure CC=clang CFLAGS="-fno-omit-frame-pointer \
+ -fsanitize=address -fsanitize=undefined -ggdb3"
+ make
+ export ASAN_OPTIONS=detect_stack_use_after_return=1
+ src/openocd -s ../tcl -f /path/to/openocd.cfg
+ @endcode
+
+Please consider performing these additonal checks where appropriate
+(especially Clang Static Analyzer for big portions of new code) and
+mention the results (e.g. "Valgrind-clean, no new Clang analyzer
+warnings") in the commit message.
Say in the commit message if it's a bugfix (describe the bug) or a new
feature. Don't expect patches to merge immediately