github-actions[bot] commented on Issue #2162:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "fuzzing"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
fitzgen commented on Issue #2162:
Could this add a parameter to
oracles::instantiate
though to assert thatModule::new
succeeds? Here I think it always should, and probably forwasm-opt -ttf
it always should as well?I think we can run up against Wasmtime-specific limits on things like number of locals and all that. I think we've hit this before with
wasm-opt -ttf
. Let me poke at it a little...
fitzgen commented on Issue #2162:
I tried asserting that the module compiles OK and hit a bug where a valid module wasn't validating with Wasmtime's version of
wasmparser
. This has since been fixed upstream, but updatingwasmparser
is a bit of a pain right now, because it hits your big refactor for module linking and all the interface changes therein as well. I spent a bit of time on updatingwasmparser
but I think we probably need to expose more methods on the new readers to get the underlying binary reader and things like that.Anyways, I think we should land this as-is, and then re-investigate asserting that the modules compile after we've updated
wasmparser
.
alexcrichton commented on Issue #2162:
Oh the main bulk of the wasmparser update is in https://github.com/bytecodealliance/wasmtime/pull/2059 and is blocked on cranelift/spidermonkey, but it's got caught up I imagine in all the changes happening recently. Looks like I need to rebase that too.
Last updated: Dec 23 2024 at 12:05 UTC