Re: Request for (i386) testing: american fuzzy lop

2014-11-22 Thread Fabian Keil 
Fabian Keil freebsd-lis...@fabiankeil.de wrote:

 Jan Beich jbe...@vfemail.net wrote:

  diff --git security/afl/Makefile security/afl/Makefile
  index e197507..db31853 100644
  --- security/afl/Makefile
  +++ security/afl/Makefile
 
 Thanks a lot for the patch, I updated the shar file and will submit it
 tomorrow provided the tarball doesn't get re-rolled again.

Submitted as #195279: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195279

Fabian


pgpg6Lk8wzWen.pgp
Description: OpenPGP digital signature

Re: Request for (i386) testing: american fuzzy lop

2014-11-21 Thread Fabian Keil 
Jan Beich jbe...@vfemail.net wrote:

 Fabian Keil freebsd-lis...@fabiankeil.de writes:
 
  Vitaly Magerya vmage...@gmail.com wrote:
  I don't know what this part is supposed to do:
  
  # Workaround to make sure clang isn't confused for gcc
  CC=${COMPILER_TYPE}
  
  ... 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+= CC=${COMPILER_TYPE}
  ?
 
 USE_GCC becomes a nop while setting explicitly fails
 
   $ uname -rp
   11.0-CURRENT amd64
 
   $ echo CC=gcc49 /etc/.make.conf
   $ make
   ...
   ===  Building for afl-0.60b
   gmake[2]: Entering directory '/work/afl-0.60b'
   [*] Checking for the ability to compile x86 code...
   [+] All done! Be sure to review README - it's pretty short and useful.
   gcc: not found
 
 Why not patch the vendor Makefile? Here're my changes:
 
   - use $(CC) --version to detect clang
   - remove -g from CFLAGS (see WITH_DEBUG)
   - strip(1) binaries during install
   - global TESTing with generic option name

Thanks a lot for the patch.

The CC detection has already been fixed upstream, but I took the
rest of the changes with the exception of renaming TEST_INSTRUMENTATION
to TEST (I think it's overloaded already, just like DOCS).
 
 while poudriere caught Clang i386 failing
 
   [*] Testing the CC wrapper and instrumentation output...
   AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O2 -pipe  
 -fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2 
 -Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.60b/lib/afl\ 
 -DDOC_PATH=\/prefix/afl-0.60b/share/doc/afl\ -DVERSION=\0.60b\ 
 -Wno-format test-instr.c -o test-instr
   /tmp/.afl-19244-1416499444.s: Assembler messages:
   /tmp/.afl-19244-1416499444.s:222: Error: unknown pseudo-op: `.cfi_sections'
   clang: error: assembler command failed with exit code 1 (use -v to see 
 invocation)

I updated the port to (hopefully) use as from ports on i386:
http://www.fabiankeil.de/sourcecode/freebsd/afl-61b.shar

Does this make a difference?

If not, I'll probably just submit the port marked as broken
for i386 and try to get this working later on.

Fabian


pgpHSQHaFfLfx.pgp
Description: OpenPGP digital signature

Re: Request for (i386) testing: american fuzzy lop

2014-11-21 Thread Jan Beich 
Fabian Keil freebsd-lis...@fabiankeil.de writes:

   [*] Testing the CC wrapper and instrumentation output...
   AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O2 -pipe
 -fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2
 -Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.60b/lib/afl\
 -DDOC_PATH=\/prefix/afl-0.60b/share/doc/afl\ -DVERSION=\0.60b\
 -Wno-format test-instr.c -o test-instr
   /tmp/.afl-19244-1416499444.s: Assembler messages:
   /tmp/.afl-19244-1416499444.s:222: Error: unknown pseudo-op: `.cfi_sections'
   clang: error: assembler command failed with exit code 1 (use -v to
 see invocation)

 I updated the port to (hopefully) use as from ports on i386:
 http://www.fabiankeil.de/sourcecode/freebsd/afl-61b.shar

 Does this make a difference?

Maybe, if you want to force devel/binutils on 9.x users. It'd be nice to
debug why clang misbehaves. Anyway, this version has wrong checksum.

  = afl-0.61b.tgz doesn't seem to exist in /portdistfiles/.
  = Attempting to fetch http://lcamtuf.coredump.cx/afl/releases/afl-0.61b.tgz
  fetch: http://lcamtuf.coredump.cx/afl/releases/afl-0.61b.tgz: size mismatch: 
expected 678088, actual 678234

After fixing I've tested on 11.0C i386, 10.1R i386, 10.0R amd64, 9.3R i386,
9.1R i386, 8.4R amd64 + tainted host on 11.0C amd64. For one, 8.x exhibit 
another old GNU as(1) issue:

  [*] Testing the CC wrapper and instrumentation output...
  AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-gcc -O2 -pipe 
-fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2 
-Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.61b/lib/afl\ 
-DDOC_PATH=\/prefix/afl-0.61b/share/doc/afl\ -DVERSION=\0.61b\ -Wno-format 
test-instr.c -o test-instr
  /tmp/.afl-16870-1416574405.s: Assembler messages:
  /tmp/.afl-16870-1416574405.s:572: Error: suffix or operands invalid for `lahf'
  /tmp/.afl-16870-1416574405.s:593: Error: suffix or operands invalid for `sahf'
  Makefile:65: recipe for target 'test_build' failed

 +.if ${ARCH} == i386
 +BUILD_DEPENDS += ${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
 +.endif
[...]
 +.if ${ARCH} == i386
 + ${REINPLACE_CMD} -e 's@\(  as_params\[0\] = \)@\1${LOCALBASE}/bin/@' \
 + ${WRKSRC}/afl-as.c
 +.endif

If ${LOCALBASE}/bin/as maybe called after install then you have to
adjust RUN_DEPENDS. Keep in mind package-only users.


 If not, I'll probably just submit the port marked as broken
 for i386 and try to get this working later on.

 Fabian

A passing by committer may also complain about PORTVERSION vs. DISTVERSION,
lack of LICENSE and DATADIR in pkg-plist.

diff --git security/afl/Makefile security/afl/Makefile
index e197507..db31853 100644
--- security/afl/Makefile
+++ security/afl/Makefile
@@ -9,7 +9,7 @@ MASTER_SITES=   http://lcamtuf.coredump.cx/afl/releases/
 MAINTAINER=f...@fabiankeil.de
 COMMENT=   Fast instrumented fuzzer
 
-USES=  gmake tar:tgz
+USES=  compiler gmake tar:tgz
 
 OPTIONS_DEFINE=DEBUG DOCS TEST_INSTRUMENTATION
 TEST_INSTRUMENTATION_DESC= Execute tests expected to fail in jails
@@ -18,10 +18,14 @@ OPTIONS_DEFAULT=DOCS
 ONLY_FOR_ARCHS=amd64 i386
 ONLY_FOR_ARCHS_REASON= Uses binary instrumentation
 
-.include bsd.port.options.mk
+# XXX replace with bsd.port.options.mk once 8.4-RELEASE is EOL
+# COMPILER_TYPE is defined in .pre without /usr/share/mk/bsd.compiler.mk
+.include bsd.port.pre.mk
 
-.if ${ARCH} == i386
+.if (${COMPILER_TYPE} == clang  ${ARCH} == i386)
+# Clang i386 emits .cfi_sections which base as(1) doesn't understand
 BUILD_DEPENDS +=   ${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
+RUN_DEPENDS += ${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
 .endif
 
 post-patch:
@@ -32,16 +36,21 @@ post-patch:
${REINPLACE_CMD} -e 's@^\(all.*\) test_build@\1@' ${WRKSRC}/Makefile
 .endif
${REINPLACE_CMD} -e 's@ -O3@@; s@ -g@@' \
-   -e 's/install -m 755/${INSTALL_PROGRAM}/' \
+   -e 's@install -m 755@${INSTALL_PROGRAM}@' \
${WRKSRC}/Makefile
-.if ${ARCH} == i386
+.if (${COMPILER_TYPE} == clang  ${ARCH} == i386)
${REINPLACE_CMD} -e 's@\(  as_params\[0\] = \)@\1${LOCALBASE}/bin/@' \
${WRKSRC}/afl-as.c
 .endif
+# XXX remove once 8.4-RELEASE is EOL
+# GNU as 2.15 doesn't understand lahf/sahf on amd64
+   ${REINPLACE_CMD} -e 's@ifdef.*\(__OpenBSD__\)@if defined(\1) || \
+   (defined(__FreeBSD__) \\ __FreeBSD__  9)@' \
+   ${WRKSRC}/afl-as.h
 
 post-install:
 .if ${PORT_OPTIONS:MDOCS}
${INSTALL_DATA} ${WRKSRC}/docs/COPYING ${STAGEDIR}${DOCSDIR}/
 .endif
 
-.include bsd.port.mk
+.include bsd.port.post.mk
diff --git security/afl/distinfo security/afl/distinfo
index 4b1882f..1b796a9 100644
--- security/afl/distinfo
+++ security/afl/distinfo
@@ -1,2 +1,2 @@
-SHA256 (afl-0.61b.tgz) = 
edff2e8f2c37041bdbb225ee7095587c1a744a3bc44f1e52491904ae986b4f9f
-SIZE (afl-0.61b.tgz) = 678088
+SHA256 (afl-0.61b.tgz) =

Re: Request for (i386) testing: american fuzzy lop

2014-11-21 Thread Dimitry Andric 
On 20 Nov 2014, at 17:51, Jan Beich jbe...@vfemail.net wrote:
...
 while poudriere caught Clang i386 failing
 
  [*] Testing the CC wrapper and instrumentation output...
  AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O2 -pipe  
 -fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2 
 -Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.60b/lib/afl\ 
 -DDOC_PATH=\/prefix/afl-0.60b/share/doc/afl\ -DVERSION=\0.60b\ 
 -Wno-format test-instr.c -o test-instr
  /tmp/.afl-19244-1416499444.s: Assembler messages:
  /tmp/.afl-19244-1416499444.s:222: Error: unknown pseudo-op: `.cfi_sections'
  clang: error: assembler command failed with exit code 1 (use -v to see 
 invocation)

This has nothing do to with clang per se, it's GNU as outputting these 
messages.  Clang just runs it, if you disable its integrated assembler.  Is 
afl-clang a customized version?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Request for (i386) testing: american fuzzy lop

2014-11-21 Thread Fabian Keil 
Dimitry Andric d...@freebsd.org wrote:

 On 20 Nov 2014, at 17:51, Jan Beich jbe...@vfemail.net wrote:
 ...
  while poudriere caught Clang i386 failing
  
   [*] Testing the CC wrapper and instrumentation output...
   AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O2 -pipe  
  -fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2 
  -Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.60b/lib/afl\ 
  -DDOC_PATH=\/prefix/afl-0.60b/share/doc/afl\ -DVERSION=\0.60b\ 
  -Wno-format test-instr.c -o test-instr
   /tmp/.afl-19244-1416499444.s: Assembler messages:
   /tmp/.afl-19244-1416499444.s:222: Error: unknown pseudo-op: `.cfi_sections'
   clang: error: assembler command failed with exit code 1 (use -v to see 
  invocation)
 
 This has nothing do to with clang per se, it's GNU as outputting these 
 messages.
 Clang just runs it, if you disable its integrated assembler.
 Is afl-clang a customized version?

afl-clang is a thin wrapper around clang that makes sure afl-as
(a wrapper around as) gets called.

Fabian


pgpRhhh8zd0Sb.pgp
Description: OpenPGP digital signature

Re: Request for (i386) testing: american fuzzy lop

2014-11-21 Thread Fabian Keil 
Jan Beich jbe...@vfemail.net wrote:

 Fabian Keil freebsd-lis...@fabiankeil.de writes:
 
[*] Testing the CC wrapper and instrumentation output...
AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O2 -pipe
  -fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2
  -Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.60b/lib/afl\
  -DDOC_PATH=\/prefix/afl-0.60b/share/doc/afl\ -DVERSION=\0.60b\
  -Wno-format test-instr.c -o test-instr
/tmp/.afl-19244-1416499444.s: Assembler messages:
/tmp/.afl-19244-1416499444.s:222: Error: unknown pseudo-op: 
  `.cfi_sections'
clang: error: assembler command failed with exit code 1 (use -v to
  see invocation)
 
  I updated the port to (hopefully) use as from ports on i386:
  http://www.fabiankeil.de/sourcecode/freebsd/afl-61b.shar
 
  Does this make a difference?
 
 Maybe, if you want to force devel/binutils on 9.x users. It'd be nice to
 debug why clang misbehaves. Anyway, this version has wrong checksum.
 
   = afl-0.61b.tgz doesn't seem to exist in /portdistfiles/.
   = Attempting to fetch http://lcamtuf.coredump.cx/afl/releases/afl-0.61b.tgz
   fetch: http://lcamtuf.coredump.cx/afl/releases/afl-0.61b.tgz: size 
 mismatch: expected 678088, actual 678234

The tarball got re-rolled ...

 After fixing I've tested on 11.0C i386, 10.1R i386, 10.0R amd64, 9.3R i386,
 9.1R i386, 8.4R amd64 + tainted host on 11.0C amd64. For one, 8.x exhibit 
 another old GNU as(1) issue:
 
   [*] Testing the CC wrapper and instrumentation output...
   AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-gcc -O2 -pipe 
 -fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2 
 -Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.61b/lib/afl\ 
 -DDOC_PATH=\/prefix/afl-0.61b/share/doc/afl\ -DVERSION=\0.61b\ 
 -Wno-format test-instr.c -o test-instr
   /tmp/.afl-16870-1416574405.s: Assembler messages:
   /tmp/.afl-16870-1416574405.s:572: Error: suffix or operands invalid for 
 `lahf'
   /tmp/.afl-16870-1416574405.s:593: Error: suffix or operands invalid for 
 `sahf'
   Makefile:65: recipe for target 'test_build' failed
 
  +.if ${ARCH} == i386
  +BUILD_DEPENDS +=   ${LOCALBASE}/bin/as:${PORTSDIR}/devel/binutils
  +.endif
 [...]
  +.if ${ARCH} == i386
  +   ${REINPLACE_CMD} -e 's@\(  as_params\[0\] = \)@\1${LOCALBASE}/bin/@' \
  +   ${WRKSRC}/afl-as.c
  +.endif
 
 If ${LOCALBASE}/bin/as maybe called after install then you have to
 adjust RUN_DEPENDS. Keep in mind package-only users.

Indeed.

 
  If not, I'll probably just submit the port marked as broken
  for i386 and try to get this working later on.

 A passing by committer may also complain about PORTVERSION vs. DISTVERSION,
 lack of LICENSE and DATADIR in pkg-plist.

I'm aware of the last two potential complaints and am prepared to
deal with them, but I'm not sure I understand the first one.

Are you suggesting that using DISTVERSION instead of PORTVERSION would
be more appropriate? At least from the comments in bsd.port.mk that's
not obvious to me.

 diff --git security/afl/Makefile security/afl/Makefile
 index e197507..db31853 100644
 --- security/afl/Makefile
 +++ security/afl/Makefile

Thanks a lot for the patch, I updated the shar file and will submit it
tomorrow provided the tarball doesn't get re-rolled again.

Fabian


pgpVjIBMoyGv7.pgp
Description: OpenPGP digital signature

Re: Request for (i386) testing: american fuzzy lop

2014-11-21 Thread Jan Beich 
Fabian Keil freebsd-lis...@fabiankeil.de writes:

 On 20 Nov 2014, at 17:51, Jan Beich jbe...@vfemail.net wrote:
 ...
  while poudriere caught Clang i386 failing
  
   [*] Testing the CC wrapper and instrumentation output...
   AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O2 -pipe
  -fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2
  -Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.60b/lib/afl\
  -DDOC_PATH=\/prefix/afl-0.60b/share/doc/afl\ -DVERSION=\0.60b\
  -Wno-format test-instr.c -o test-instr
   /tmp/.afl-19244-1416499444.s: Assembler messages:
   /tmp/.afl-19244-1416499444.s:222: Error: unknown pseudo-op: 
  `.cfi_sections'
   clang: error: assembler command failed with exit code 1 (use -v
  to see invocation)
 
 This has nothing do to with clang per se, it's GNU as outputting these 
 messages.
 Clang just runs it, if you disable its integrated assembler.
 Is afl-clang a customized version?

 afl-clang is a thin wrapper around clang that makes sure afl-as
 (a wrapper around as) gets called.

In clang case, afl-as should feed the modified assembly back to the
compiler, not to GNU as. Try replacing |as| with |${CC} -c| except
adjusting positional parameters may slightly complicate it.


 Fabian

-

VFEmail.net - http://www.vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Request for (i386) testing: american fuzzy lop

2014-11-20 Thread Fabian Keil 
I'm looking for testers for a port of American fuzzy lop.

Quoting the pkg-descr:
| American fuzzy lop is a fuzzer that employs a novel type of compile-time
| instrumentation and genetic algorithms to automatically discover clean,
| interesting test cases that trigger new internal states in the targeted
| binary. This substantially improves the functional coverage for the
| fuzzed code.
|
| WWW: http://lcamtuf.coredump.cx/afl/

The shar file is available at:
http://www.fabiankeil.de/sourcecode/freebsd/afl-60b.shar

The port is supposed to work on amd64 and i386 but so far
it has only been tested on amd64 (with 64bit binaries).

By default the port is supposed to build in jails, but actually
using it requires shmget() which is unlikely to be available in
build jails.

If you have access to an i386 system, but no time to read documentation,
you can still help by building a package outside a jail with the
TEST_INSTRUMENTATION option enabled.

Fabian


pgpXfhI1gtocq.pgp
Description: OpenPGP digital signature

Re: Request for (i386) testing: american fuzzy lop

2014-11-20 Thread Vitaly Magerya 
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-time
 | instrumentation and genetic algorithms to automatically discover clean,
 | interesting test cases that trigger new internal states in the targeted
 | binary. This substantially improves the functional coverage for the
 | fuzzed code.
 |
 | WWW: http://lcamtuf.coredump.cx/afl/

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.

 The shar file is available at:
 http://www.fabiankeil.de/sourcecode/freebsd/afl-60b.shar
 
 The port is supposed to work on amd64 and i386 but so far
 it has only been tested on amd64 (with 64bit binaries).

I don't know what this part is supposed to do:

# Workaround to make sure clang isn't confused for gcc
CC=${COMPILER_TYPE}

... but it seems to set CC to empty string on my machine; and I
get a whole bunch of this as the result:

--version: not found
make: /usr/ports/Mk/Uses/compiler.mk line 66: warning:
 --version returned non-zero status

I also get this:

 ===  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
 
 Oops, looks like your compiler can't generate x86 code.
 
 (If you are looking for ARM, see experimental/arm_support/README.)
 
 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'
 === Compilation failed unexpectedly.

Missing GCC dependency?

(This is all on 10.0-RELEASE amd64).
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Request for (i386) testing: american fuzzy lop

2014-11-20 Thread Fabian Keil 
Vitaly Magerya vmage...@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-time
  | instrumentation and genetic algorithms to automatically discover clean,
  | interesting test cases that trigger new internal states in the targeted
  | binary. This substantially improves the functional coverage for the
  | fuzzed code.
  |
  | WWW: http://lcamtuf.coredump.cx/afl/
 
 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.
 
  The shar file is available at:
  http://www.fabiankeil.de/sourcecode/freebsd/afl-60b.shar
  
  The port is supposed to work on amd64 and i386 but so far
  it has only been tested on amd64 (with 64bit binaries).
 
 I don't know what this part is supposed to do:
 
 # Workaround to make sure clang isn't confused for gcc
 CC=${COMPILER_TYPE}
 
 ... 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+= CC=${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
 
 I also get this:
 
  ===  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
  
  Oops, looks like your compiler can't generate x86 code.
  
  (If you are looking for ARM, see experimental/arm_support/README.)
  
  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'
  === Compilation failed unexpectedly.
 
 Missing GCC dependency?

The base compiler should be fine, this is probably just the
fallout of the clobbered CC.
 
 (This is all on 10.0-RELEASE amd64).

Thanks for testing.

Fabian


pgpHZlAV7GB5F.pgp
Description: OpenPGP digital signature

Re: Request for (i386) testing: american fuzzy lop

2014-11-20 Thread Vitaly Magerya 
On 11/20/14 17:02, Fabian Keil wrote:
 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.

I was working with version 0.27b, so I guess lots of things changed
since then. They even have afl-clang now.

 Does it work for you if you replace the line with:
 MAKE_ARGS+=   CC=${COMPILER_TYPE}
 ?

Yes, this fixes all the problems; AFL now installs fine.

I also tested actually compiling stuff with afl-clang and then running
afl-fuzz, which also seems to work.

I don't have an i386 system though.

 And if not, does it work if you remove it completely?

Removing it does not work ('test_build' fails).
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Request for (i386) testing: american fuzzy lop

2014-11-20 Thread Fabian Keil 
Vitaly Magerya vmage...@gmail.com wrote:

 On 11/20/14 17:02, Fabian Keil wrote:
 
  Does it work for you if you replace the line with:
  MAKE_ARGS+= CC=${COMPILER_TYPE}
  ?
 
 Yes, this fixes all the problems; AFL now installs fine.

Great, thanks for the feedback. I updated the shar file in place.

Fabian


pgpyvKdGEvoVP.pgp
Description: OpenPGP digital signature

Re: Request for (i386) testing: american fuzzy lop

2014-11-20 Thread Jan Beich 
Fabian Keil freebsd-lis...@fabiankeil.de writes:

 Vitaly Magerya vmage...@gmail.com wrote:
 I don't know what this part is supposed to do:
 
 # Workaround to make sure clang isn't confused for gcc
 CC=${COMPILER_TYPE}
 
 ... 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+=   CC=${COMPILER_TYPE}
 ?

USE_GCC becomes a nop while setting explicitly fails

  $ uname -rp
  11.0-CURRENT amd64

  $ echo CC=gcc49 /etc/.make.conf
  $ make
  ...
  ===  Building for afl-0.60b
  gmake[2]: Entering directory '/work/afl-0.60b'
  [*] Checking for the ability to compile x86 code...
  [+] All done! Be sure to review README - it's pretty short and useful.
  gcc: not found

Why not patch the vendor Makefile? Here're my changes:

  - use $(CC) --version to detect clang
  - remove -g from CFLAGS (see WITH_DEBUG)
  - strip(1) binaries during install
  - global TESTing with generic option name

while poudriere caught Clang i386 failing

  [*] Testing the CC wrapper and instrumentation output...
  AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. ./afl-clang -O2 -pipe  
-fstack-protector -fno-strict-aliasing -Wall -D_FORTIFY_SOURCE=2 
-Wno-pointer-sign -DAFL_PATH=\/prefix/afl-0.60b/lib/afl\ 
-DDOC_PATH=\/prefix/afl-0.60b/share/doc/afl\ -DVERSION=\0.60b\ -Wno-format 
test-instr.c -o test-instr
  /tmp/.afl-19244-1416499444.s: Assembler messages:
  /tmp/.afl-19244-1416499444.s:222: Error: unknown pseudo-op: `.cfi_sections'
  clang: error: assembler command failed with exit code 1 (use -v to see 
invocation)

diff --git security/afl/Makefile security/afl/Makefile
index d7b2c93..bbe2992 100644
--- security/afl/Makefile
+++ security/afl/Makefile
@@ -9,10 +9,9 @@ MASTER_SITES=  http://lcamtuf.coredump.cx/afl/releases/
 MAINTAINER=f...@fabiankeil.de
 COMMENT=   Fast instrumented fuzzer
 
-USES=  compiler gmake tar:tgz
+USES=  gmake tar:tgz
 
-OPTIONS_DEFINE=DOCS TEST_INSTRUMENTATION
-TEST_INSTRUMENTATION_DESC= Execute tests expected to fail in jails
+OPTIONS_DEFINE=DOCS TEST
 OPTIONS_DEFAULT=   DOCS
 
 ONLY_FOR_ARCHS=amd64 i386
@@ -20,17 +19,17 @@ ONLY_FOR_ARCHS_REASON=  Uses binary instrumentation
 
 .include bsd.port.options.mk
 
-# Workaround to make sure clang isn't confused for gcc
-MAKE_ARGS+=CC=${COMPILER_TYPE}
-
 post-patch:
-.if ! ${PORT_OPTIONS:MTEST_INSTRUMENTATION}
+.if ! ${PORT_OPTIONS:MTEST}
 # afl needs shmget() which usually isn't available in jails. Disabling
 # the instrumentation tests makes sure building packages in jails works
 # by default anyway.
${REINPLACE_CMD} -e 's@^\(all.*\) test_build@\1@' ${WRKSRC}/Makefile
 .endif
-   ${REINPLACE_CMD} -e 's@-O3@@' ${WRKSRC}/Makefile
+   ${REINPLACE_CMD} -e 's@ -O3@@; s@ -g@@' \
+   -e '/findstring clang/s@$$(CC)@$$(shell  --version)@' \
+   -e 's/install -m 755/${INSTALL_PROGRAM}/' \
+   ${WRKSRC}/Makefile
 
 post-install:
 .if ${PORT_OPTIONS:MDOCS}

-

VFEmail.net - http://www.vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org