Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi value! And even more fuzzing! #124

merged 12 commits into from Sep 5, 2019


Copy link

fitzgen commented Aug 29, 2019

fixes #77

@fitzgen fitzgen requested a review from alexcrichton Aug 29, 2019
@fitzgen fitzgen force-pushed the fitzgen:multi-value branch from aa3ac29 to 5d991ef Aug 30, 2019

This comment has been minimized.

Copy link
Member Author

fitzgen commented Aug 30, 2019

It looks like some change here (probably related to blocks having types or making the types shared) is making the types come out in non-deterministic orders. I'm going to solve this with an explicit sorting step for emitting types.

Copy link

alexcrichton left a comment

Nice! Mind running a few benchmarks to ensure that the usage of Mutex/Arc don't regress our current parsing performance?

I'm also curious, could you explain a bit more where the need for interior mutability arose?

fuzz/fuzz_targets/ Outdated Show resolved Hide resolved Show resolved Hide resolved
src/module/ Outdated Show resolved Hide resolved
src/module/ Outdated Show resolved Hide resolved
fitzgen added 5 commits Jun 6, 2019
This commit adds support for parsing, emitting, and manipulating multi-value
Instead of holding a couple of `Box<[ValType]>`s for parameters and results, now
they more accurately reflect the spec (and the multi-value extension of it). For
simple, MVP wasm, they hold the optional return value type directly inline. For
multi-value, they reference a `TypeId`. See the `NB` comment above
`InstrSeqType` for details about why this split is beneficial, and we
shouldn't *only* use `TypeId`.
This will let us define custom RNGs that are controlled via libFuzzer and/or
AFL, so that we can get coverage-guided fuzzing instead of purely random
@fitzgen fitzgen force-pushed the fitzgen:multi-value branch from e3c2901 to 9db93b8 Sep 4, 2019
fitzgen added 4 commits Aug 29, 2019
Re-uses basically all of our existing fuzzing infrastructure, but uses libfuzzer
to drive the "RNG" values that we generate Wat with. This lets us combine the
benefits of coverage-guided fuzzing with our existing "structured" fuzzing.
This is not /strictly/ necessary because they are otherwise emitted in the order
that they are added, which is usually the order that they are parsed. However,
if one were adding types in a non-deterministic order, then we would emit types
non-deterministically. Overall, this is just a nice robustness addition.
@fitzgen fitzgen force-pushed the fitzgen:multi-value branch from 9db93b8 to fc3379b Sep 4, 2019
@fitzgen fitzgen force-pushed the fitzgen:multi-value branch from fc3379b to 3c0b187 Sep 4, 2019
@fitzgen fitzgen merged commit da63e75 into rustwasm:master Sep 5, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
@fitzgen fitzgen deleted the fitzgen:multi-value branch Sep 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.