This repository has been archived by the owner on Mar 24, 2022. It is now read-only.
x86_64 Linux clang -m32 is not a perfect oracle for lucet-wasi-fuzz #445
Comments
acfoltzer
added a commit
that referenced
this issue
Mar 12, 2020
Disable the fuzz CI job and add a warning to lucet-wasi-fuzz till #445 is resolved
cfallin
added a commit
that referenced
this issue
Dec 16, 2020
This commit adds options to the `csmith` invocation in lucet-wasi-fuzz to avoid generating any programs with `long long` types or 64-bit math. This seems to avoid the issues in #445 (mismatch between i386 ABI and wasm32 ABI w.r.t. alignment of 8-byte types) so far. For convenience, this also flips the feature flag in lucetc to use the new backend.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There is at least one key difference:
alignof(long long) == 4withclang -m32, butalignof(long long) == 8withwasi-sdk/bin/clang. While I'm not convinced that all of our recent fuzz failures are due to this alignment issue, it makes it very difficult to shrink the resulting test cases with creduce.We should probably include a non-Cranelift Wasm engine in the fuzz loop as an additional oracle, but if we treat another Wasm engine as the oracle we lose the ability to distinguish potential problems in
wasi-sdk/bin/clang, which would then be compiling the Wasm for both the oracle and the test. In the meantime, though, it would at least give us meaningful fuzzing data for Lucet and Cranelift.The text was updated successfully, but these errors were encountered: