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

On Fri, Aug 25, 2017 at 8:51 AM, Daniel Sanders <daniel_l_sanders at
apple.com>
wrote:
> (removed my @imgtec.com address since it no longer exists)
>
> Sorry for the slow reply, it's a busy time for me right now.
>
> > On 23 Aug 2017, at 00:21, George Karpenkov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > As a part of a recent move of libFuzzer from LLVM to compiler-rt I am
> looking into updating the build code
> > for the libraries which use libFuzzer.
> >
> > I have tried to compile llvm-mc-assemble-fuzzer, and
> llvm-mc-disassemble-fuzzer, and I couldn’t build either of those.
> > For the first one, the reason is that it refers to a nonexistent enum,
>
> I don't seem to be able to build this with cmake+ninja yet (I'm
having
> trouble recursing the compiler on macOS) but after manually building it...
> It seems this broke at the start of August when the CodeModel argument was
> removed from InitMCObjectFileInfo(). After removing that argument and
> adding an 'extern "C"' it at least compiles. I
haven't had chance to try
> running it yet.
>
> > and for the second one I believe the reason is that it does not
enclose
> LLVMFuzzerTestOneInput in “extern ‘C’”.
>
> I agree we need an "extern C" here. I'm not sure what changed
to make it
> required though.
>
> > Are those libraries maintained and/or used?
>
> I haven't used it for quite a while now. My original motivator was the
> Mips assembler/disassembler being very buggy. I was using it to find
> crashes and generate interesting test cases for round-trip testing of the
> assembler/disassembler. Since then, the Mips MC layer has become much more
> stable and I've also changed jobs.
>
> That said, I'd like to set up a bot to make use of these tools,

As soon as these fuzz targets build, don't immediately crash, and have
someone who cares about them,
I can add them to OSS-Fuzz for automated continuous fuzzing.


> it's mostly a matter of finding time for it. That's normally
difficult but
> I should be able to do that in the next few weeks.
>
> > If yes, the code should be compilable, and ideally there should be a
> buildbot.
> > 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)
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170825/6ea54ec5/attachment.html>

> On 25 Aug 2017, at 17:26, Kostya Serebryany <kcc at google.com>
wrote:
> 
> 
> 
> On Fri, Aug 25, 2017 at 8:51 AM, Daniel Sanders <daniel_l_sanders at
apple.com <mailto:daniel_l_sanders at apple.com>> wrote:
> (removed my @imgtec.com <http://imgtec.com/> address since it no
longer exists)
> 
> Sorry for the slow reply, it's a busy time for me right now.
> 
> > On 23 Aug 2017, at 00:21, George Karpenkov via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > Hi,
> >
> > As a part of a recent move of libFuzzer from LLVM to compiler-rt I am
looking into updating the build code
> > for the libraries which use libFuzzer.
> >
> > I have tried to compile llvm-mc-assemble-fuzzer, and
llvm-mc-disassemble-fuzzer, and I couldn’t build either of those.
> > For the first one, the reason is that it refers to a nonexistent enum,
> 
> I don't seem to be able to build this with cmake+ninja yet (I'm
having trouble recursing the compiler on macOS) but after manually building
it... It seems this broke at the start of August when the CodeModel argument was
removed from InitMCObjectFileInfo(). After removing that argument and adding an
'extern "C"' it at least compiles. I haven't had chance to
try running it yet.
> 
> > and for the second one I believe the reason is that it does not
enclose LLVMFuzzerTestOneInput in “extern ‘C’”.
> 
> I agree we need an "extern C" here. I'm not sure what changed
to make it required though.
> 
> > Are those libraries maintained and/or used?
> 
> I haven't used it for quite a while now. My original motivator was the
Mips assembler/disassembler being very buggy. I was using it to find crashes and
generate interesting test cases for round-trip testing of the
assembler/disassembler. Since then, the Mips MC layer has become much more
stable and I've also changed jobs.
> 
> That said, I'd like to set up a bot to make use of these tools, 
> 
> As soon as these fuzz targets build, don't immediately crash, and have
someone who cares about them,
> I can add them to OSS-Fuzz for automated continuous fuzzing. 
I had an out-of-tree target in mind but it would be great to test the in-tree
targets with OSS-Fuzz.
> it's mostly a matter of finding time for it. That's normally
difficult but I should be able to do that in the next few weeks.
> 
> > If yes, the code should be compilable, and ideally there should be a
buildbot.
> > 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)
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170825/17379dae/attachment.html>

Kostya Serebryany <kcc at google.com> writes:
> On Fri, Aug 25, 2017 at 8:51 AM, Daniel Sanders <daniel_l_sanders at
apple.com> wrote:
>> On 23 Aug 2017, at 00:21, George Karpenkov via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>> I have tried to compile llvm-mc-assemble-fuzzer, and
>>> llvm-mc-disassemble-fuzzer, and I couldn’t build either of those.
>>> For the first one, the reason is that it refers to a nonexistent
>>> enum,
 ...
>>> Are those libraries maintained and/or used?
>>
>> I haven't used it for quite a while now. My original motivator was
the
>> Mips assembler/disassembler being very buggy. I was using it to find
>> crashes and generate interesting test cases for round-trip testing of
the
>> assembler/disassembler. Since then, the Mips MC layer has become much
more
>> stable and I've also changed jobs.
>>
>> That said, I'd like to set up a bot to make use of these tools,
>
> As soon as these fuzz targets build, don't immediately crash, and have
> someone who cares about them, I can add them to OSS-Fuzz for automated
> continuous fuzzing.
These both compile and run again as of r312011, though I suspect they'll
need some small changes to play well in OSS Fuzz and the like. They use
an approach to command line arguments that won't work for features like
-merge or parallel fuzzing (they could pretty easily be updated to use
"-ignore_remaining_args=1" like llvm-isel-fuzzer does though).

On Tue, Aug 29, 2017 at 10:15 AM, Justin Bogner <mail at justinbogner.com>
wrote:
> Kostya Serebryany <kcc at google.com> writes:
> > On Fri, Aug 25, 2017 at 8:51 AM, Daniel Sanders <
> daniel_l_sanders at apple.com> wrote:
> >> On 23 Aug 2017, at 00:21, George Karpenkov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>> I have tried to compile llvm-mc-assemble-fuzzer, and
> >>> llvm-mc-disassemble-fuzzer, and I couldn’t build either of
those.
> >>> For the first one, the reason is that it refers to a
nonexistent
> >>> enum,
>  ...
> >>> Are those libraries maintained and/or used?
> >>
> >> I haven't used it for quite a while now. My original motivator
was the
> >> Mips assembler/disassembler being very buggy. I was using it to
find
> >> crashes and generate interesting test cases for round-trip testing
of
> the
> >> assembler/disassembler. Since then, the Mips MC layer has become
much
> more
> >> stable and I've also changed jobs.
> >>
> >> That said, I'd like to set up a bot to make use of these
tools,
> >
> > As soon as these fuzz targets build, don't immediately crash, and
have
> > someone who cares about them, I can add them to OSS-Fuzz for automated
> > continuous fuzzing.
>
> These both compile and run again as of r312011, though I suspect
they'll
> need some small changes to play well in OSS Fuzz and the like. They use
> an approach to command line arguments that won't work for features like
> -merge or parallel fuzzing (they could pretty easily be updated to use
> "-ignore_remaining_args=1" like llvm-isel-fuzzer does though).
>
Yep. I may not have time to update these fuzzers though. Volunteers?
Also, even with -ignore_remaining_args=1 we may not be able to use them
(and llvm-isel-fuzzer) on oss-fuzz.


I'd suggest to at least change llvm-isel-fuzzer (and others) to have a
default value of flags, such that running e.g.
./bin/llvm-isel-fuzzer  # no flags
will work (and fuzz one default config).

If we like how it works on oss-fuzz, we may then extend  llvm-isel-fuzzer
to parse the command arguments (or a config type, etc) from the
executable's name.

--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170829/8dbcf98d/attachment.html>