Fix target compilation, we had 10%+ speed loss ... #377
Conversation
One of the possible reasons of the decrement in performance of AFL++ in the lastest report is due to the missing AFL_ALIGNED_ALLOC env var. Without this variable, dislocator's malloc does not ensure that the returned address is aligned to max_aligned_t (as required by posix) but it is able, in this way, to catch more bugs. Many applications checks for this alignment and this may cause an early exit in the application (and so a low coverage). I completely remove dislocator to better understand what is happening in the next run of the experiments.
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
|
there is still a 5% performance loss ... |
|
now it is ... ok. could be better. I compiled afl++ without any optimization and the targets with over-optimization and hence the outcome was 20% lower than it should have been. That affected only fuzzbench though, not the normal releases. For some things I am still clueless. a binary that is generated with clang is better compiled than via afl-clang-fast, although the only differences are some -D__AFL defines and -Warnings stuff. stumps me. |
|
OK this is done now. I added a very special variant - shared memory fuzzing. This should result (hopefully) in ~ 10-25% speed in all targets. If you could run aflplusplus, aflpluspus_optimal and aflplusplus_shmem and then combine it with 2020-05-24? |
No description provided.