Wasmtime GitHub notifications bot (Jul 21 2026 at 01:40): Wasmtime GitHub notifications bot (Jul 21 2026 at 01:40):jlb6740 opened PR #13915 from jlb6740:xed-fuzz-support to bytecodealliance:main:
The roundtrip fuzzer compares assembled instructions against Capstone, which cannot decode newer encodings such as APX. Add Intel XED as an optional second oracle:
- Refactor the roundtrip core into
roundtrip_with(...)so the Capstone path and a new XED path share one implementation (Capstone logic is unchanged, just extracted).- Implement
disassemble_xedandxed_matches(normalizing whitespace, immediates, SIB scale-of-1, and operand-size/vector-length suffixes).- Gate XED behind a new off-by-default
fuzz-xedfeature, since it builds XED from source, and add a matchingroundtrip-xedlibFuzzer target.- Add the
smoke_xedtest,#[ignore]d while normalization (e.g. condition-code aliases) is still a work in progress.- Vet: exempt
xed-sysand itstarget-lexiconrequirement.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Jul 21 2026 at 01:40):jlb6740 requested cfallin for a review on PR #13915.
Wasmtime GitHub notifications bot (Jul 21 2026 at 01:40):jlb6740 requested wasmtime-compiler-reviewers for a review on PR #13915.
Wasmtime GitHub notifications bot (Jul 21 2026 at 01:40):jlb6740 requested wasmtime-default-reviewers for a review on PR #13915.
Wasmtime GitHub notifications bot (Jul 21 2026 at 01:40):jlb6740 requested alexcrichton for a review on PR #13915.
Wasmtime GitHub notifications bot (Jul 21 2026 at 01:51):jlb6740 commented on PR #13915:
Hi, looking to restart work on this issue https://github.com/bytecodealliance/wasmtime/issues/12157 to enable APX. I am using the plan at the issue as reference but also just trying to enable an end to end example (assembler to file testing) of an APX instruction (https://github.com/bytecodealliance/wasmtime/pull/13916). W.r.t. fuzzing, capstone does not support APX but xed does. This patch allows an alternative oracle to capstone regardless of if APX is ever implemented, but is also necessary for APX fuzzing. The upstream xed sys crate needs to be updated as the APX spec has likely evolved for some corner cases not covered in the current spec, but before pursuing that I wanted to see if this plan is supported and if we can merge support for what is upstream today.
Wasmtime GitHub notifications bot (Jul 21 2026 at 03:52):github-actions[bot] added the label cranelift on PR #13915.
Wasmtime GitHub notifications bot (Jul 21 2026 at 20:13):alexcrichton commented on PR #13915:
Thanks! Could the xed paths be tested in CI? If you want them fuzzed as well they'll either need to be on-by-default or enabled explicitly in oss-fuzz. Also, there's a lot of updates to the lock file here -- could that be reset and then regenerated? (a stray
cargo updateprobably caused lots of updates)
Wasmtime GitHub notifications bot (Jul 22 2026 at 05:20):jlb6740 updated PR #13915.
Wasmtime GitHub notifications bot (Jul 22 2026 at 15:13)::memo: alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jul 22 2026 at 15:13)::speech_balloon: alexcrichton created PR review comment:
In addition to the testing-on-CI concern, could this get folded into the
miscfuzzer instead of making a new fuzzer?
Wasmtime GitHub notifications bot (Jul 23 2026 at 00:13)::memo: jlb6740 submitted PR review.
Wasmtime GitHub notifications bot (Jul 23 2026 at 00:13)::speech_balloon: jlb6740 created PR review comment:
In addition to the testing-on-CI concern, could this get folded into the
miscfuzzer instead of making a new fuzzer?Hi @alexcrichton, yes will do. I will also add CI support and eventually support in oss-fuzz once it's been vetted here for a period of time.
Wasmtime GitHub notifications bot (Jul 28 2026 at 02:13):jlb6740 requested alexcrichton for a review on PR #13915.
Wasmtime GitHub notifications bot (Jul 28 2026 at 02:13):jlb6740 requested wasmtime-fuzz-reviewers for a review on PR #13915.
Wasmtime GitHub notifications bot (Jul 28 2026 at 02:13):jlb6740 updated PR #13915.
Wasmtime GitHub notifications bot (Jul 28 2026 at 02:50):jlb6740 updated PR #13915.
Wasmtime GitHub notifications bot (Jul 28 2026 at 05:36):github-actions[bot] added the label fuzzing on PR #13915.
Wasmtime GitHub notifications bot (Jul 28 2026 at 05:36):github-actions[bot] commented on PR #13915:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "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>
Wasmtime GitHub notifications bot (Jul 28 2026 at 17:36)::memo: jlb6740 submitted PR review.
Wasmtime GitHub notifications bot (Jul 28 2026 at 17:36)::speech_balloon: jlb6740 created PR review comment:
@alexcrichton I believe I've addressed your comments, folding the misc fuzzer in 1dfe815, and adding CI coverage in 7b9f8b4".
Wasmtime GitHub notifications bot (Jul 28 2026 at 18:11)::speech_balloon: jlb6740 edited PR review comment.
Wasmtime GitHub notifications bot (Jul 28 2026 at 18:13)::speech_balloon: jlb6740 edited PR review comment.
Wasmtime GitHub notifications bot (Jul 28 2026 at 18:50):alexcrichton commented on PR #13915:
There's a huge amount of heavy lifting here going on in the comparison of xed's output to what this assembler outputs, and while that's not too bad since this is only related to fuzzing I'm also wondering if this is something where there might be a better way of handling this. One possible way of doing this is that instructions are stringifed with
format("{inst}")and this syntax means we could use theFormatter::alternateflag for "do something else". In this situationformat!("{inst}")could use capstone syntax andformat!("{inst:#}")could use xed syntax.Do you have a sense if that sould help encapsulate the differences here? Alternatively maybe it'd make sense to just output the xed syntax and switch to that as the oracle in fuzzing? Capstone is also a big C dependency so building a big C project isn't necessarily the end of the world.
Overall I'm mostly just wary of how there's such a large volume of code necessary to bridge capstone/xed disassembly. ~100 lines would be fine but ~700 feels like it's pushing things a bit
Last updated: Jul 29 2026 at 05:03 UTC