@@ -77,6 +77,37 @@ patch:
7777 src/openocd -s ../tcl -f /path/to/openocd.cfg
7878 @endcode
7979
80+ - Sparse Static Analyzer
81+
82+ Using this tool allows identifying some bug in C code.
83+ In the future, OpenOCD would use the sparse attribute 'bitwise' to
84+ detect incorrect endianness assignments.
85+
86+ Example usage:
87+ @code
88+ mkdir build-sparse; cd build-sparse
89+ ../configure CC=cgcc CFLAGS="-Wsparse-all -Wno-declaration-after-statement \
90+ -Wno-unknown-attribute -Wno-transparent-union -Wno-tautological-compare \
91+ -Wno-vla -Wno-flexible-array-array -D__FLT_EVAL_METHOD__=0"
92+ make
93+ @endcode
94+
95+ - Code coverage analysis
96+
97+ By inspecting the code coverage, you can identify potential gaps in your testing
98+ and use that information to improve your test scenarios.
99+
100+ Example usage:
101+ @code
102+ mkdir build-gcov; cd build-gcov
103+ ../configure --enable-gcov [...]
104+ make
105+ # ... Now execute your test scenarios to collect OpenOCD code coverage ...
106+ lcov --capture --directory ./src --output-file openocd-coverage.info
107+ genhtml openocd-coverage.info --output-directory coverage_report
108+ # ... Open coverage_report/index.html in a web browser ...
109+ @endcode
110+
80111Please consider performing these additional checks where appropriate
81112(especially Clang Static Analyzer for big portions of new code) and
82113mention the results (e.g. "Valgrind-clean, no new Clang analyzer
@@ -140,10 +171,6 @@ topics. It is possible because @c for/master is not a traditional Git
140171branch.
141172 -# You will need to install this hook, we will look into a better solution:
142173@code
143- scp -p -P 29418 USERNAME@review.openocd.org:hooks/commit-msg .git/hooks/
144- @endcode
145- Or with http only:
146- @code
147174wget https://review.openocd.org/tools/hooks/commit-msg
148175mv commit-msg .git/hooks
149176chmod +x .git/hooks/commit-msg
@@ -171,18 +198,48 @@ while(!done) {
171198@endcode
172199 \note use "git add ." before commit to add new files.
173200
174- Comment template, notice the short first line w/topic. The topic field
175- should identify the main part or subsystem the patch touches. Check
176- git log for examples.
177- @code
178- topic: Short comment
201+ \note check @ref checkpatch for hint about checkpatch script
202+
203+ Commit message template, notice the short first line.
204+ The field '<c>specify touched area</c>'
205+ should identify the main part or subsystem the patch touches.
206+ @code{.unparsed}
207+ specify touched area: short comment
179208<blank line>
180209Longer comments over several lines, explaining (where applicable) the
181210reason for the patch and the general idea the solution is based on,
182- any major design decisions, etc...
211+ any major design decisions, etc. Limit each comment line's length to 75
212+ characters; since 75 it's too short for a URL, you can put the URL in a
213+ separate line preceded by 'Link: '.
183214<blank line>
184215Signed-off-by: ...
185216@endcode
217+ Examples:
218+ @code{.unparsed}
219+ flash/nor/atsame5: add SAME59 support
220+
221+ Add new device ID
222+ @endcode
223+ @code{.unparsed}
224+ flash/nor: flash driver for XYZ123
225+
226+ Add new flash driver for internal flash of ...
227+ @endcode
228+ @code{.unparsed}
229+ target/cortex_m: fix segmentation fault in cmd 'soft_reset_halt'
230+
231+ soft_reset_halt command failed reproducibly under following conditions: ...
232+ Test for NULL pointer and return error ...
233+
234+ Reported-by: John Reporter <rep9876@gmail.com>
235+ Fixes: 123456789abc ("target: the commit where the problem started")
236+ BugLink: https://sourceforge.net/p/openocd/tickets/999/
237+ @endcode
238+ @code{.unparsed}
239+ doc: fix typos
240+ @endcode
241+ See "git log" for more examples.
242+
186243-# Next you need to make sure that your patches
187244 are on top of the latest stuff on the server and
188245 that there are no conflicts:
@@ -201,6 +258,72 @@ git push review
201258
202259Further reading: http://www.coreboot.org/Git
203260
261+ @section checkpatch About checkpatch script
262+
263+ OpenOCD source code includes the script checkpatch to let developers to
264+ verify their patches before submitting them for review (see @ref gerrit).
265+
266+ Every patch for OpenOCD project that is submitted for review on Gerrit
267+ is tested by Jenkins. Jenkins will run the checkpatch script to analyze
268+ each patch.
269+ If the script highlights either errors or warnings, Gerrit will add the
270+ score "-1" to the patch and maintainers will probably ignore the patch,
271+ waiting for the developer to send a fixed version.
272+
273+ The script checkpatch verifies the SPDX tag for new files against a very
274+ short list of license tags.
275+ If the license of your contribution is not listed there, but compatible
276+ with OpenOCD license, please alert the maintainers or add the missing
277+ license in the first patch of your patch series.
278+
279+ The script checkpatch has been originally developed for the Linux kernel
280+ source code, thus includes specific tests and checks related to Linux
281+ coding style and to Linux code structure. While the script has been
282+ adapted for OpenOCD specificities, it still includes some Linux related
283+ test. It is then possible that it triggers sometimes some <em>false
284+ positive</em>!
285+
286+ If you think that the error identified by checkpatch is a false
287+ positive, please report it to the openocd-devel mailing list or prepare
288+ a patch for fixing checkpatch and send it to Gerrit for review.
289+
290+ \attention The procedure below is allowed only for <em>exceptional
291+ cases</em>. Do not use it to submit normal patches.
292+
293+ There are <em>exceptional cases</em> in which you need to skip some of
294+ the tests from checkpatch in order to pass the approval from Gerrit.
295+
296+ For example, a patch that modify one line inside a big comment block
297+ will not show the beginning or the end of the comment block. This can
298+ prevent checkpatch to detect the comment block. Checkpatch can wrongly
299+ consider the modified comment line as a code line, triggering a set of
300+ false errors.
301+
302+ Only for <em>exceptional cases</em>, it is allowed to submit patches
303+ to Gerrit with the special field 'Checkpatch-ignore:' in the commit
304+ message. This field will cause checkpatch to ignore the error types
305+ listed in the field, only for the patch itself.
306+ For errors in the commit message, the special field has to be put in
307+ the commit message before the line that produces the error.
308+ The special field must be added <em>before</em> the 'Signed-off-by:'
309+ line, otherwise it is ignored.
310+ To ignore multiple errors, either add multiple lines with the special
311+ field or add multiple error types, separated by space or commas, in a
312+ single line.
313+ The error type is printed by checkpatch on failure.
314+ For example the names of Windows APIs mix lower and upper case chars,
315+ in violation of OpenOCD coding style, triggering a 'CAMELCASE' error:
316+ @code
317+ CHECK:CAMELCASE: Avoid CamelCase: <WSAGetLastError>
318+ #96105: FILE: src/helper/log.c:505:
319+ + error_code = WSAGetLastError();
320+ @endcode
321+ Adding in the commit message of the patch the line:
322+ @code
323+ Checkpatch-ignore: CAMELCASE
324+ @endcode
325+ will force checkpatch to ignore the CAMELCASE error.
326+
204327@section timeline When can I expect my contribution to be committed?
205328
206329The code review is intended to take as long as a week or two to allow
0 commit comments