#define R(x) (random() % (x))
This breaks clang's APInt.h, which uses R() as a function and doesn't expect
it to get mapped to something random... suggest changing this to something
less likely to conflict with anything else called R. More generally, some
sort of namespace cleanup would be good, there are macros in there with
generic enough names that they might conflict with future changes to clang
headers.
Peter.
[*] Checking for working 'llvm-config'...
[*] Checking for working 'clang'...
[*] Checking for '../afl-showmap'...
[+] All set and ready to build.
[*] Building 32-bit variant of the runtime (-m32)... failed (that's fine)
[*] Testing the CC wrapper and instrumentation output...
unset AFL_USE_ASAN AFL_USE_MSAN AFL_INST_RATIO; AFL_QUIET=1 AFL_PATH=. AFL_CC=clang ../afl-clang-fast -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"2.41b\" ../test-instr.c -o test-instr
clang-5.0: error: unable to execute command: Segmentation fault
clang-5.0: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 5.0.0 (trunk 301638)
Peter.
I've fiddled with it a bit but I've got a pile of other work to clear at the moment, and I'm not sure if I'll have time to dig into the internals of afl-clang-fast, sorry.
As another bit of feedback, hardcoding in AFL_PATH and BIN_PATH to need-to-be-root locations is a bit of a pain since the binaries are present in .. relative to the llvm_mode directory, I'm currently overriding them with .. but I'm not sure whether that has any long-term consequences. In fact running afl-clang-fast naked, without all the -Dxxx stuff, didn't appear to break anything so I'm not sure if they're necessary.
Peter.