Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-01T00:09:42Z

Sweet. Always wanted to try AFL but never got to it.

Ran it for 2 minutes (which know is nothing the the grand scheme). Perhaps you can set it up to use only ASCII to speed things up - as any control chars are unlikely to be interesting.

Original Redmine Comment
Author Name: Eric Rippey
Original Date: 2019-10-01T00:50:54Z

As far as I know there isn't an option to keep the inputs ASCII.

There is an option to use a collection of interesting strings. That could be used to make the fuzzer know the whole set of valid keywords for Verilog and the set of valid symbols. I would expect that this would make things way more efficient. I've never used this option though and someone would have to write this list.

A different thing that can be done to speed up the fuzzer is to give it a larger corpus of examples to start with. In my example script, I created a single starting point, but to find the bugs that I filed I started with a set of around 1000 short files that I had around for other reasons. A good place to start might be to point it at the existing files in the test_regress/t directory.

You're right that two minutes is nowhere near how long things are expected to take. Assuming that you're seeing the number of paths found increase, it's not a bad idea to leave it to run overnight although I was seeing some results within the first half hour.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-01T01:53:46Z

This is much appreciated.

1. First legal stuff, do you agree what you attach and future contributions are open source as described here? https://developercertificate.org/

How far do you want to take this? Not sure if you are willing to do more work, certainly would be helpful. Here's some suggestions based on your ideas:

2. Make nodist/* files we can put in the distro that run with "cwd" in the root of the verilator kit (e.g. cd ; nodist/fuzzer). (Seems like just a few tweaks needed for this.)

3. Add corpus from test_regress?

4. Limit to ASCII if possible?

5. Add words based on tokens from verilog.l, maybe with the letters a-z for symbol use?

Original Redmine Comment
Author Name: Eric Rippey
Original Date: 2019-10-07T17:31:22Z

The contributor agreement is fine.

At this point, I don't have a real bird's eye view of the how the project works to be able to how exactly things should be integrated. For example, where would you want this in the tree?

And where would this be expected to be run? Is there a set of platforms that I should make sure things work on? From reading the bug about using Travis CI, it seems like there isn't a set of dedicated machines anywhere to run things on.

Is there a document somewhere that lays out some development guidelines? For example, one of the scripts that I attached is Python and that might be the first piece of Python in the tree.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-07T23:06:41Z

I'd suggest putting the files under the "nodist" directory, this is for things that are developer only and don't need to go into a tarball.

I personally ran the fuzzing from the $VERILATOR_ROOT directory (where the .git file is.)

I don't think we'd fuzz on Travis-CI, basically if if works on a standard Linux distro like Ubuntu 18.04 we're good.

There's some information in docs/CONTRIBUTING.adoc and docs/internals.adoc that might be of interest. (Make sure you pull first as these were recently cleaned up.)

Thanks for looking into this.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-17T02:20:22Z

Scripts pushed to git.

Know there will be minor changes to e.g. ignore some internal errors, feel free to send as pull requests, or post a new issue.