Stream: git-wasmtime

Topic: wasmtime / issue #3574 ISLE: fuzz generated code with on-...

view this post on Zulip Wasmtime GitHub notifications bot (Nov 30 2021 at 20:09):

cfallin opened issue #3574:

In this comment on ISLE documentation, @avanhatt mentioned fuzzing as related to the Context trait that separates generated code from the Cranelift glue. This got me thinking that there is actually a nice way we could fuzz the ISLE-generated code independently.

Specifically, we could write an alternate implementation of the Context that stubs out external constructors, and that implements all external extractors in terms of an arbitrary::Unstructured state that it carries. As the pattern-matching makes queries about its input by calling external extractors, the context object could invent answers on the fly with Arbitrary implementations.

This would allow us both to test the generated code to look for unexpected panics -- for example, if we have unreachable!() anywhere -- and to look for inefficiencies/timeouts, e.g. if there is an infinite recursion.

There is some maintenance effort involved (separate implementation of each external etor/ctor that we add) but it might be worthwhile; thoughts?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 30 2021 at 21:01):

alexcrichton labeled issue #3574:

In this comment on ISLE documentation, @avanhatt mentioned fuzzing as related to the Context trait that separates generated code from the Cranelift glue. This got me thinking that there is actually a nice way we could fuzz the ISLE-generated code independently.

Specifically, we could write an alternate implementation of the Context that stubs out external constructors, and that implements all external extractors in terms of an arbitrary::Unstructured state that it carries. As the pattern-matching makes queries about its input by calling external extractors, the context object could invent answers on the fly with Arbitrary implementations.

This would allow us both to test the generated code to look for unexpected panics -- for example, if we have unreachable!() anywhere -- and to look for inefficiencies/timeouts, e.g. if there is an infinite recursion.

There is some maintenance effort involved (separate implementation of each external etor/ctor that we add) but it might be worthwhile; thoughts?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 30 2021 at 21:02):

github-actions[bot] commented on issue #3574:

Subscribe to Label Action

cc @cfallin, @fitzgen

<details>
This issue or pull request has been labeled: "isle"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2022 at 20:02):

cfallin labeled issue #3574:

In this comment on ISLE documentation, @avanhatt mentioned fuzzing as related to the Context trait that separates generated code from the Cranelift glue. This got me thinking that there is actually a nice way we could fuzz the ISLE-generated code independently.

Specifically, we could write an alternate implementation of the Context that stubs out external constructors, and that implements all external extractors in terms of an arbitrary::Unstructured state that it carries. As the pattern-matching makes queries about its input by calling external extractors, the context object could invent answers on the fly with Arbitrary implementations.

This would allow us both to test the generated code to look for unexpected panics -- for example, if we have unreachable!() anywhere -- and to look for inefficiencies/timeouts, e.g. if there is an infinite recursion.

There is some maintenance effort involved (separate implementation of each external etor/ctor that we add) but it might be worthwhile; thoughts?

Last updated: Dec 23 2024 at 12:05 UTC