afl-llvm won't build with the latest clang release

371 views
Skip to first unread message

Peter Gutmann

unread,
Apr 28, 2017, 10:15:22 AM4/28/17
to afl-...@googlegroups.com
AFL's custom types.h has:

#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.

Peter Gutmann

unread,
Apr 28, 2017, 10:36:26 AM4/28/17
to afl-...@googlegroups.com
And as a corollary to that, running afl-clang-fast segfaults, but I'll have to
look into that tomorrow:

[*] 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.

Michal Zalewski

unread,
Apr 28, 2017, 12:42:41 PM4/28/17
to afl-users
> #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...

Oops. Let me know if you figure the crash out - otherwise, I'll
download and build latest clang.

> More generally, some sort of namespace cleanup would be good,

Yeah, llvm_mode is a bit of a retrofit, the macros and constants
pulled from AFL .h files were not meant to end up in other projects,
so they don't have distinctive prefixes or so.

/mz

Peter Gutmann

unread,
Apr 30, 2017, 11:02:14 PM4/30/17
to afl-...@googlegroups.com
>Oops. Let me know if you figure the crash out - otherwise, I'll
>download and build latest clang.

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.

Michal Zalewski

unread,
Apr 30, 2017, 11:17:35 PM4/30/17
to afl-users
> As another bit of feedback, hardcoding in AFL_PATH and BIN_PATH to need-to-be-root locations is a bit of a pain

You can override that by setting PREFIX in the environment when
calling make. It should allow for local non-root installs in somewhere
like ~/bin/.

Cheers,
/mz
Reply all
Reply to author
Forward
0 new messages