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

>
>
> 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()

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

>
> > Who else wants to be automatically CC-ed to all trophies?
> > (I'll need to add your e-mail here:
> > https://github.com/google/oss-fuzz/blob/master/projects/
> llvm/project.yaml)
> >
> >
> >>
> >> I hope Daniel can answer the other questions.
> >>
> >>
> >>> If no, maybe we should remove it, or move it to a separate
repository.
> >>>
> >>> Thanks,
> >>> George
> >>>
> >>> (sorry for starting multiple threads, I believe this way it is
more
> >>> convenient to keep track of tasks)
> >>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170824/6e5d8379/attachment.html>

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

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>