Stream: git-wasmtime

Topic: wasmtime / Issue #2079 machinst x64: investigate remainin...

Wasmtime GitHub notifications bot (Jul 29 2020 at 15:57):

bnjbvr labeled Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [ ] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [ ] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Wasmtime GitHub notifications bot (Jul 29 2020 at 15:57):

bnjbvr opened Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [ ] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [ ] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Wasmtime GitHub notifications bot (Jul 30 2020 at 00:16):

jlb6740 edited Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [x] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [ ] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Wasmtime GitHub notifications bot (Jul 30 2020 at 00:17):

jlb6740 edited Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [ ] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [ ] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Wasmtime GitHub notifications bot (Jul 30 2020 at 00:30):

jlb6740 commented on Issue #2079:

@bnjbvr Hi .. How do you test to see all the failures? If you run:

cargo test --all --features=experimental_x64

or under the cranelift project:

RUST_BACKTRACE=1` RUST_LOG=debug cargo test --all --features=experimental_x64 --package cranelift-codegen -- --nocapture

you see failures I believe related to the first bullet on stack onwinding .. but those are the only ones I can see fail.

Wasmtime GitHub notifications bot (Jul 30 2020 at 13:29):

bnjbvr commented on Issue #2079:

A commit has now landed in CI with the right command line to use for running all the test cases; it's a bit long and requires Rust nightly (because of the way Cargo feature unification works in stable vs nightly):

        cargo \
            -Zfeatures=all -Zpackage-features \
            test \
            --features test-programs/test_programs \
            --features experimental_x64 \
            --all \
            --exclude lightbeam \
            --exclude peepmatic \
            --exclude peepmatic-automata \
            --exclude peepmatic-fuzzing \
            --exclude peepmatic-macro \
            --exclude peepmatic-runtime \
            --exclude peepmatic-test

Wasmtime GitHub notifications bot (Jul 30 2020 at 13:29):

bnjbvr edited a comment on Issue #2079:

A commit has now landed in CI with the right command line to use for running all the test cases; it's a bit long and requires Rust nightly (because of the way Cargo feature unification works in stable vs nightly):

        cargo +nightly \
            -Zfeatures=all -Zpackage-features \
            test \
            --features test-programs/test_programs \
            --features experimental_x64 \
            --all \
            --exclude lightbeam \
            --exclude peepmatic \
            --exclude peepmatic-automata \
            --exclude peepmatic-fuzzing \
            --exclude peepmatic-macro \
            --exclude peepmatic-runtime \
            --exclude peepmatic-test

Wasmtime GitHub notifications bot (Jul 30 2020 at 22:03):

jlb6740 commented on Issue #2079:

Thanks ... see this now after updating the version of nightly. Did not see any errors but will take a closer look at the tests that are disabled.

Wasmtime GitHub notifications bot (Sep 24 2020 at 14:06):

bnjbvr labeled Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [ ] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [ ] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Wasmtime GitHub notifications bot (Sep 24 2020 at 14:06):

github-actions[bot] commented on Issue #2079:

Subscribe to Label Action

cc @bnjbvr

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

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

• bnjbvr: cranelift

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 (Sep 24 2020 at 15:40):

bnjbvr edited Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [ ] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [x] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Wasmtime GitHub notifications bot (Sep 24 2020 at 15:42):

bnjbvr edited Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [x] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [x] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Wasmtime GitHub notifications bot (Mar 20 2021 at 09:19):

bjorn3 commented on Issue #2079:

implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)

This is done.

tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.

Is this done?

Wasmtime GitHub notifications bot (Mar 20 2021 at 20:26):

cfallin commented on Issue #2079:

I think so; we don't have any excluded GC tests anymore.

Wasmtime GitHub notifications bot (Mar 20 2021 at 20:26):

cfallin closed Issue #2079:

Opening an issue as a placeholder for remaining issues observed during testing. Initial PR for landing excluded the following tests:

• [ ] implement proper stack unwinding for the new backend: codegen/src/isa/x86/unwind/{systemv, winx64}.rs, tests/all/traps.rs (also: this will require implementing the win64 fastcall ABI in x64)
• [x] cranelift filetests. For those, we'd need to either make them dependent on the Cargo feature x64 being not present (for e.g. regalloc tests), or keep them enabled (e.g. run tests). It will require more triaging. One idea would be to create a new directory x64 in the filetests suite, and copy over the tests that can be ported there; then we'd need some kind of way to dispatch the x64 tests to the new backend only, and x86 to the old backend only.
• [ ] tests/all/gc.rs: investigate the gc-during-gc test failure. Probably a miscompilation in new-backend x64, since aarch64 doens't seem to fail this test.
• [x] tests/all/iloop.rs, tests/all/stack_overflow.rs: probably require implementing probe stacks for both. The first file relates to interrupts, which might or might not be handled the same way as stack overflows in Wasmtime; I don't know.

Last updated: Oct 23 2024 at 20:03 UTC