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 fitzgen commented Aug 29, 2019

fixes #77

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 alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/functions/local_function/ Show resolved Hide resolved
src/module/ Outdated Show resolved Hide resolved
src/module/ Outdated Show resolved Hide resolved
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 commit adds support for parsing, emitting, and manipulating multi-value
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
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 merged commit da63e75 into rustwasm:master Sep 5, 2019
@fitzgen fitzgen deleted the multi-value branch September 5, 2019 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

Support multi-value proposal
2 participants