[llvm-dev] llvm-mc-[dis]assemble-fuzzer status?

[Kostya Serebryany via llvm-dev]

On Thu, Aug 24, 2017 at 2:59 PM, Justin Bogner <mail at justinbogner.com>
wrote:

> Kostya Serebryany <kcc at google.com> writes:
> >> I'd like llvm-isel-fuzzer to be added once its committed
> >
> > consider it done (once it's there)
> >
> >> (which should be as soon as LLVM fuzzers work in release builds
> >> again). One potential issue is that llvm-isel-fuzzer is more of a
> >> collection of fuzzers, and it needs some arguments to run (ie, to
> >> choose the backend).
> >
> > I have the same problem with clang-proto-fuzzer, which uses the same
> > approach with flags as llvm-isel-fuzzer.
> >
> > The solution I was thinking about is (drum roll!) to encode the flags in
> > the binary name, e.g.
> > "./llvm-isel-fuzzer,-flag1,-flag2" and then read these flags from
> argv[0]
> > in LLVMFuzzerInitialize()
>
> This is just horrible enough that it might work.
>

This is not unheard of, right?
clang++ is a link to clang, but they actually behave in different ways


>
> > Then in oss-fuzz build.sh we will just do this:
> > for flags in -flag1a,-flag1b -flag2a,-flag2b; do
> >   cp llvm-isel-fuzzer $OUT/llvm-isel-fuzzer,$flags
> > done
>
> Would it work to just create a simple shell script that forwards to the
> "real" fuzzer binary? Ie,
>
>   echo 'llvm-isel-fuzzer "$@" --ignore-remaining-flags=1
> -mtriple=aarch64-apple-ios -global-isel -O0' >
> llvm-isel-fuzzer-aarch64-gisel
>
> Then we could just tell OSS-Fuzz that llvm-isel-fuzzer-aarch64-gisel is
> what we want to run. Depending on what OSS-Fuzz does with the binary I
> could see this failing, of course.
>

This is unlikely to work with AFL and may complicate things for us in
future.
I am reluctant to support this in case we have some other fuzzing
mechanisms that won't not support this.

--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170824/8191e297/attachment-0001.html>