Fossil SCM
Minor tweaks to the fuzzer section of build.wiki.
Commit
dfb1234f937c490540e95e133fee95f91e71fe565b90cc12efb1771cd3cf7fda
Parent
1a397ee35f8f09d…
1 file changed
+9
-8
+9
-8
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -386,21 +386,22 @@ | ||
| 386 | 386 | |
| 387 | 387 | <a id='fuzzer'></a> |
| 388 | 388 | <h2>Building for Fuzz Testing</h2> |
| 389 | 389 | |
| 390 | 390 | This feature is primarily intended for fossil's developers and may |
| 391 | -change at any time. It is only known to work on x86/64 Linux systems. | |
| 391 | +change at any time. It is only known to work on Linux systems and has | |
| 392 | +been seen to work on x86/64 and ARM. | |
| 392 | 393 | |
| 393 | 394 | Fossil has builtin support for processing specific features using |
| 394 | -<tt>libfuzzer</tt>. The specific features which can be tested this way | |
| 395 | -are found in the help text for the [/help?cmd=test-fuzz|test-fuzz | |
| 395 | +<tt>libfuzzer</tt>. The features which can be tested this way are | |
| 396 | +found in the help text for the [/help?cmd=test-fuzz|test-fuzz | |
| 396 | 397 | command]. |
| 397 | 398 | |
| 398 | 399 | Fuzzing requires: |
| 399 | 400 | |
| 400 | 401 | * Customizing the build of fossil a small bit. |
| 401 | - * The clang compiler. | |
| 402 | + * The clang C compiler. | |
| 402 | 403 | * libfuzzer. On Ubuntu-derived systems, it can be installed with |
| 403 | 404 | <tt>apt install libfuzzer-XYZ</tt>, where XYZ is a version number |
| 404 | 405 | (several versions may be available on any given system) |
| 405 | 406 | |
| 406 | 407 | |
| @@ -432,14 +433,14 @@ | ||
| 432 | 433 | # processor, copy any to-be-tested .md files into that directory. |
| 433 | 434 | # Then start the fuzzer: |
| 434 | 435 | $ ./fossil-fuzz --fuzztype markdown cases |
| 435 | 436 | </code></pre> |
| 436 | 437 | |
| 437 | -As it works, it writes its test files into the test-input directory, | |
| 438 | -each one named in the form of a hash. When it finds a problem it will | |
| 439 | -produce a stack trace for the offending code, will output the | |
| 440 | -name of the file which triggered the crash (named | |
| 438 | +As it works, it writes its mutated test files into the test-input | |
| 439 | +directory, each one named in the form of a hash. When it finds a | |
| 440 | +problem it will produce a stack trace for the offending code, will | |
| 441 | +output the name of the file which triggered the crash (named | |
| 441 | 442 | <tt>cases/SOME_HASH</tt>) and may, depending on the nature of the |
| 442 | 443 | problem, produce a file named <tt>crash-SOMETHING</tt>. In theory the |
| 443 | 444 | crash file can be fed directly back into the fuzzer to reproduce the |
| 444 | 445 | problem: |
| 445 | 446 | |
| 446 | 447 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -386,21 +386,22 @@ | |
| 386 | |
| 387 | <a id='fuzzer'></a> |
| 388 | <h2>Building for Fuzz Testing</h2> |
| 389 | |
| 390 | This feature is primarily intended for fossil's developers and may |
| 391 | change at any time. It is only known to work on x86/64 Linux systems. |
| 392 | |
| 393 | Fossil has builtin support for processing specific features using |
| 394 | <tt>libfuzzer</tt>. The specific features which can be tested this way |
| 395 | are found in the help text for the [/help?cmd=test-fuzz|test-fuzz |
| 396 | command]. |
| 397 | |
| 398 | Fuzzing requires: |
| 399 | |
| 400 | * Customizing the build of fossil a small bit. |
| 401 | * The clang compiler. |
| 402 | * libfuzzer. On Ubuntu-derived systems, it can be installed with |
| 403 | <tt>apt install libfuzzer-XYZ</tt>, where XYZ is a version number |
| 404 | (several versions may be available on any given system) |
| 405 | |
| 406 | |
| @@ -432,14 +433,14 @@ | |
| 432 | # processor, copy any to-be-tested .md files into that directory. |
| 433 | # Then start the fuzzer: |
| 434 | $ ./fossil-fuzz --fuzztype markdown cases |
| 435 | </code></pre> |
| 436 | |
| 437 | As it works, it writes its test files into the test-input directory, |
| 438 | each one named in the form of a hash. When it finds a problem it will |
| 439 | produce a stack trace for the offending code, will output the |
| 440 | name of the file which triggered the crash (named |
| 441 | <tt>cases/SOME_HASH</tt>) and may, depending on the nature of the |
| 442 | problem, produce a file named <tt>crash-SOMETHING</tt>. In theory the |
| 443 | crash file can be fed directly back into the fuzzer to reproduce the |
| 444 | problem: |
| 445 | |
| 446 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -386,21 +386,22 @@ | |
| 386 | |
| 387 | <a id='fuzzer'></a> |
| 388 | <h2>Building for Fuzz Testing</h2> |
| 389 | |
| 390 | This feature is primarily intended for fossil's developers and may |
| 391 | change at any time. It is only known to work on Linux systems and has |
| 392 | been seen to work on x86/64 and ARM. |
| 393 | |
| 394 | Fossil has builtin support for processing specific features using |
| 395 | <tt>libfuzzer</tt>. The features which can be tested this way are |
| 396 | found in the help text for the [/help?cmd=test-fuzz|test-fuzz |
| 397 | command]. |
| 398 | |
| 399 | Fuzzing requires: |
| 400 | |
| 401 | * Customizing the build of fossil a small bit. |
| 402 | * The clang C compiler. |
| 403 | * libfuzzer. On Ubuntu-derived systems, it can be installed with |
| 404 | <tt>apt install libfuzzer-XYZ</tt>, where XYZ is a version number |
| 405 | (several versions may be available on any given system) |
| 406 | |
| 407 | |
| @@ -432,14 +433,14 @@ | |
| 433 | # processor, copy any to-be-tested .md files into that directory. |
| 434 | # Then start the fuzzer: |
| 435 | $ ./fossil-fuzz --fuzztype markdown cases |
| 436 | </code></pre> |
| 437 | |
| 438 | As it works, it writes its mutated test files into the test-input |
| 439 | directory, each one named in the form of a hash. When it finds a |
| 440 | problem it will produce a stack trace for the offending code, will |
| 441 | output the name of the file which triggered the crash (named |
| 442 | <tt>cases/SOME_HASH</tt>) and may, depending on the nature of the |
| 443 | problem, produce a file named <tt>crash-SOMETHING</tt>. In theory the |
| 444 | crash file can be fed directly back into the fuzzer to reproduce the |
| 445 | problem: |
| 446 | |
| 447 |