Lines Matching +refs:is +refs:effective +refs:target

10 ! llvm_mode works with llvm versions 3.8 up to 17 - but 13+ is recommended !
21   The gains are less pronounced for fast binaries, where the speed is limited
25 - The instrumentation is CPU-independent. At least in principle, you should be
31 - Because the feature relies on the internals of LLVM, it is clang-specific and
32   will *not* work with GCC (see ../gcc_plugin/ for an alternative once it is
35 Once this implementation is shown to be sufficiently robust and portable, it
63 It is highly recommended to use the newest clang version you can put your hands
71 system. You should also make sure that the llvm-config tool is in your path (or
76 you installation is set up correctly :-)
79 LLVM development headers; one example of this is FreeBSD. FreeBSD users will
92 called afl-clang-fast and afl-clang-fast++ in the parent directory. Once this is
111 is not honored as it does not serve a good purpose with the more effective
126 Then there are different ways of instrumenting the target:
130    is the best option you can use. To go with this option, use
136     one. This explodes the map but on the other hand has proven to be effective
144 Then - additionally to one of the instrumentation options above - there is a
145 very effective new instrumentation option called CmpLog as an alternative to
149 Finally, if your llvm version is 8 or lower, you can activate a mode that
150 prevents that a counter overflow result in a 0 value. This is good for path
151 discovery, but the llvm implementation for x86 for this functionality is not
155 `AFL_LLVM_THREADSAFE_INST=1`. The tradeoff is better precision in multi threaded
161 This is the most powerful and effective fuzzing you can do. For a full
176 ### What is this?
178 This is an LLVM-based implementation of the context sensitive branch coverage.
180 Basically every function gets its own ID and, every time when an edge is logged,
188 In math the coverage is collected as follows: `map[current_location_ID ^
191 The callstack hash is produced XOR-ing the function IDs to avoid explosion with
198 It is highly recommended to increase the MAP_SIZE_POW2 definition in config.h to
208 In math the coverage is collected as follows: `map[current_location_ID ^
218 This is an LLVM-based implementation of the n-gram branch coverage proposed in
224 [here](https://github.com/bitsecurerlab/afl-sensitive)) is built on top of AFL's
225 QEMU mode. This is essentially a port that uses LLVM vectorized instructions
229 In math the branch coverage is performed as follows: `map[current_location ^
234 The size of `n` (i.e., the number of branches to remember) is an option that is
239 It is highly recommended to increase the MAP_SIZE_POW2 definition in config.h to
246 collect the edge coverage can easily fill up and wrap around. This is not that
248 program execution ends. In this case, afl-fuzz is not able to see that the edge
258 This is implemented in afl-gcc and afl-gcc-fast, however, for llvm_mode this is
259 optional if multithread safe counters are selected or the llvm version is below
276 If the target does not have extensive loops or functions that are called a lot,
286 Measuring source code coverage is a common task in fuzzing, but it is very
299 respective parts in the AFL compiler runtime. Support is currently only
303 that your coverage map is large enough to hold all basic blocks of your
304 target program without any collisions.