cfallin opened Issue #2582:
We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.
As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended on a subtle way on initial (undefined) register state. (Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because
x == x
always... except whenx
is NaN, hence nondeterministic failures.) Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.
cfallin edited Issue #2582:
We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.
As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended on a subtle way on initial (undefined) register state. Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because
x == x
always... except whenx
is NaN, hence nondeterministic failures. Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.We would likely benefit at least from the undefined-state tracking, as in above. ABI and VM interface-adjacent work (which tend to be pointer-heavy) may benefit from memcheck as well.
cfallin edited Issue #2582:
We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.
As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended in a subtle way on initial (undefined) register state. Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because
x == x
always... except whenx
is NaN, hence nondeterministic failures. Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.We would likely benefit at least from the undefined-state tracking, as in above. ABI and VM interface-adjacent work (which tend to be pointer-heavy) may benefit from memcheck as well.
julian-seward1 commented on Issue #2582:
For best avoidance of false positives, I'd suggest to use a snapshot of the trunk (
git://sourceware.org/git/valgrind.git
) if possible. Also, if you do find anything that looks like a false positive, do let me know .. the battle against them is ongoing.
bnjbvr labeled Issue #2582:
We should consider adding a CI job that runs at least the Cranelift Wasm spec tests using Valgrind. This would allow us to more easily and deterministically catch subtle issues with generated code.
As an example, in #2432, we found that we were JIT'ing a sequence of instructions that depended in a subtle way on initial (undefined) register state. Specifically, we used an SSE compare instruction, comparing a temp reg against itself to produce all-ones, because
x == x
always... except whenx
is NaN, hence nondeterministic failures. Valgrind correctly models the semantics of the compare instruction that we used, and detected that our generated code depended on the initial (undefined) value of an XMM register.We would likely benefit at least from the undefined-state tracking, as in above. ABI and VM interface-adjacent work (which tend to be pointer-heavy) may benefit from memcheck as well.
Last updated: Nov 22 2024 at 17:03 UTC