Date: Thu, 20 Nov 2014 16:02:10 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: freebsd-ports@freebsd.org Subject: Re: Request for (i386) testing: american fuzzy lop Message-ID: <3fb914c3.1002708a@fabiankeil.de> In-Reply-To: <546DF8A5.3060601@gmail.com> References: <3dc1c153.7b7b9177@fabiankeil.de> <546DF8A5.3060601@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/16oSSN+9mouF6h/mBRbDkL7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Vitaly Magerya <vmagerya@gmail.com> wrote: > On 2014-11-20 14:43, Fabian Keil wrote:> Quoting the pkg-descr: > > | American fuzzy lop is a fuzzer that employs a novel type of compile-t= ime > > | instrumentation and genetic algorithms to automatically discover clea= n, > > | interesting test cases that trigger new internal states in the target= ed > > | binary. This substantially improves the functional coverage for the > > | fuzzed code. > > | > > | WWW: http://lcamtuf.coredump.cx/afl/ >=20 > I very much welcome this effort; I myself have tried to create a port > for it, but it required a whole lot of hacks (AFL is intertwined with > internals of GCC, which I failed to make work); I ended up needing > to rewrite it's assembly filters in a fairly hackish way... Can't > remember precisely what the problem was though. 0.57b and later have "[f]ixes to make things work on FreeBSD and OpenBSD: use_64bit is inferred if not explicitly specified when calling afl-as". If you started with an earlier release, this might have been the problem. =20 > > The shar file is available at: > > http://www.fabiankeil.de/sourcecode/freebsd/afl-60b.shar > >=20 > > The port is supposed to work on amd64 and i386 but so far > > it has only been tested on amd64 (with 64bit binaries). >=20 > I don't know what this part is supposed to do: >=20 > # Workaround to make sure clang isn't confused for gcc > CC=3D${COMPILER_TYPE} >=20 > ... but it seems to set CC to empty string on my machine; and I > get a whole bunch of this as the result: Interesting. It was supposed to set CC for gmake to either clang or gcc, otherwise a cc that is clang is treated as gcc. However clobbering CC directly is obviously wrong and on systems where cc is still gcc, the workaround shouldn't be necessary anyway. Does it work for you if you replace the line with: MAKE_ARGS+=3D CC=3D${COMPILER_TYPE} ? And if not, does it work if you remove it completely? > --version: not found > make: "/usr/ports/Mk/Uses/compiler.mk" line 66: warning: > " --version" returned non-zero status >=20 > I also get this: >=20 > > =3D=3D=3D> Building for afl-0.60b > > gmake[2]: Entering directory '/tmp/ports/security/afl/work/afl-0.60b' > > [*] Checking for the ability to compile x86 code... > > gcc: not found > >=20 > > Oops, looks like your compiler can't generate x86 code. > >=20 > > (If you are looking for ARM, see experimental/arm_support/README.) > >=20 > > Makefile:46: recipe for target 'test_x86' failed > > gmake[2]: *** [test_x86] Error 1 > > gmake[2]: Leaving directory '/tmp/ports/security/afl/work/afl-0.60b' > > =3D=3D=3D> Compilation failed unexpectedly. >=20 > Missing GCC dependency? The base compiler should be fine, this is probably just the fallout of the clobbered CC. =20 > (This is all on 10.0-RELEASE amd64). Thanks for testing. Fabian --Sig_/16oSSN+9mouF6h/mBRbDkL7 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRuAnIACgkQBYqIVf93VJ2iHACfSf0RpOxnSpH61C82/R1xf9kh FL0An09vbxC1pKD6e2jo/SoE72apJYX8 =aF48 -----END PGP SIGNATURE----- --Sig_/16oSSN+9mouF6h/mBRbDkL7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3fb914c3.1002708a>