plicease opened Issue #1716:
- What are the steps to reproduce the issue?
- Adjust the multi.c example that comes with wasmtime #1715
- compile and run on aarch64
pi1% env RUST_BACKTRACE=1 ./a.out Initializing... Compiling module... thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1063 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204 9: std::panicking::default_hook at src/libstd/panicking.rs:224 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:470 11: std::panicking::begin_panic 12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs 13: cranelift_codegen::machinst::lower::Lower<I>::lower 14: cranelift_codegen::machinst::compile::compile 15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function 16: cranelift_codegen::context::Context::compile 17: cranelift_codegen::context::Context::compile_and_emit 18: wasmtime_jit::compiler::make_trampoline 19: wasmtime_jit::compiler::Compiler::compile 20: wasmtime_jit::instantiate::CompiledModule::new 21: wasmtime::module::Module::from_binary_unchecked 22: wasmtime::module::Module::from_binary 23: wasmtime_module_new 24: main 25: __libc_start_main 26: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. fatal runtime error: failed to initiate panic, error 3705270992 Abort (core dumped)
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?Expect the program to run without fail as it does on x86_64. multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.
- Which Wasmtime version / commit hash / branch are you using?
This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)Raspberry Pi Ubuntu Focal
pi1% uname -a Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.
plicease labeled Issue #1716:
- What are the steps to reproduce the issue?
- Adjust the multi.c example that comes with wasmtime #1715
- compile and run on aarch64
pi1% env RUST_BACKTRACE=1 ./a.out Initializing... Compiling module... thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1063 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204 9: std::panicking::default_hook at src/libstd/panicking.rs:224 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:470 11: std::panicking::begin_panic 12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs 13: cranelift_codegen::machinst::lower::Lower<I>::lower 14: cranelift_codegen::machinst::compile::compile 15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function 16: cranelift_codegen::context::Context::compile 17: cranelift_codegen::context::Context::compile_and_emit 18: wasmtime_jit::compiler::make_trampoline 19: wasmtime_jit::compiler::Compiler::compile 20: wasmtime_jit::instantiate::CompiledModule::new 21: wasmtime::module::Module::from_binary_unchecked 22: wasmtime::module::Module::from_binary 23: wasmtime_module_new 24: main 25: __libc_start_main 26: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. fatal runtime error: failed to initiate panic, error 3705270992 Abort (core dumped)
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?Expect the program to run without fail as it does on x86_64. multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.
- Which Wasmtime version / commit hash / branch are you using?
This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)Raspberry Pi Ubuntu Focal
pi1% uname -a Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.
plicease edited Issue #1716:
- What are the steps to reproduce the issue?
- Adjust the multi.c example that comes with wasmtime #1715
- compile and run on aarch64
pi1% env RUST_BACKTRACE=1 ./a.out Initializing... Compiling module... thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1063 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204 9: std::panicking::default_hook at src/libstd/panicking.rs:224 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:470 11: std::panicking::begin_panic 12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs 13: cranelift_codegen::machinst::lower::Lower<I>::lower 14: cranelift_codegen::machinst::compile::compile 15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function 16: cranelift_codegen::context::Context::compile 17: cranelift_codegen::context::Context::compile_and_emit 18: wasmtime_jit::compiler::make_trampoline 19: wasmtime_jit::compiler::Compiler::compile 20: wasmtime_jit::instantiate::CompiledModule::new 21: wasmtime::module::Module::from_binary_unchecked 22: wasmtime::module::Module::from_binary 23: wasmtime_module_new 24: main 25: __libc_start_main 26: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. fatal runtime error: failed to initiate panic, error 3705270992 Abort (core dumped)
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?Expect the program to run without fail as it does on x86_64. If multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.
- Which Wasmtime version / commit hash / branch are you using?
This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)Raspberry Pi Ubuntu Focal
pi1% uname -a Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.
alexcrichton labeled Issue #1716:
- What are the steps to reproduce the issue?
- Adjust the multi.c example that comes with wasmtime #1715
- compile and run on aarch64
pi1% env RUST_BACKTRACE=1 ./a.out Initializing... Compiling module... thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1063 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204 9: std::panicking::default_hook at src/libstd/panicking.rs:224 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:470 11: std::panicking::begin_panic 12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs 13: cranelift_codegen::machinst::lower::Lower<I>::lower 14: cranelift_codegen::machinst::compile::compile 15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function 16: cranelift_codegen::context::Context::compile 17: cranelift_codegen::context::Context::compile_and_emit 18: wasmtime_jit::compiler::make_trampoline 19: wasmtime_jit::compiler::Compiler::compile 20: wasmtime_jit::instantiate::CompiledModule::new 21: wasmtime::module::Module::from_binary_unchecked 22: wasmtime::module::Module::from_binary 23: wasmtime_module_new 24: main 25: __libc_start_main 26: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. fatal runtime error: failed to initiate panic, error 3705270992 Abort (core dumped)
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?Expect the program to run without fail as it does on x86_64. If multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.
- Which Wasmtime version / commit hash / branch are you using?
This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)Raspberry Pi Ubuntu Focal
pi1% uname -a Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.
alexcrichton commented on Issue #1716:
I've only got access to an emulator, but if debug assertions are enabled it looks like there's a preceding problem which may be the root of the issue here:
thread '<unnamed>' panicked at 'assertion failed: rets.iter().all(|a| match a { &ABIArg::Stack(..) => false, _ => true, })', cranelift/codegen/src/isa/aarch64/abi.rs:225:9
(which is this line)
<details>
<summary>stack trace</summary>
thread '<unnamed>' panicked at 'assertion failed: rets.iter().all(|a| match a { &ABIArg::Stack(..) => false, _ => true, })', cranelift/codegen/src/isa/aarch64/abi.rs:225:9 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1063 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204 9: std::panicking::default_hook at src/libstd/panicking.rs:224 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:470 11: std::panicking::begin_panic at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panicking.rs:397 12: cranelift_codegen::isa::aarch64::abi::ABISig::from_func_sig at cranelift/codegen/src/isa/aarch64/abi.rs:225 13: cranelift_codegen::isa::aarch64::abi::AArch64ABIBody::new at cranelift/codegen/src/isa/aarch64/abi.rs:372 14: cranelift_codegen::isa::aarch64::AArch64Backend::compile_vcode at cranelift/codegen/src/isa/aarch64/mod.rs:49 15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function at cranelift/codegen/src/isa/aarch64/mod.rs:61 16: cranelift_codegen::context::Context::compile at cranelift/codegen/src/context.rs:186 17: cranelift_codegen::context::Context::compile_and_emit at cranelift/codegen/src/context.rs:132 18: wasmtime_environ::cranelift::compile::{{closure}} at crates/environ/src/cranelift.rs:358 19: core::ops::function::impls::<impl core::ops::function::Fn<A> for &F>::call at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/ops/function.rs:242 20: <rayon::iter::map_with::MapWithFolder<C,U,F> as rayon::iter::plumbing::Folder<T>>::consume_iter::with::{{closure}} at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/map_with.rs:317 21: core::iter::adapters::map_try_fold::{{closure}} at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:779 22: core::iter::traits::iterator::Iterator::try_fold at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/traits/iterator.rs:1877 23: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:805 24: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:805 25: <core::iter::adapters::TakeWhile<I,P> as core::iter::traits::iterator::Iterator>::try_fold at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:1750 26: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:805 27: <core::iter::adapters::TakeWhile<I,P> as core::iter::traits::iterator::Iterator>::try_fold at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/adapters/mod.rs:1750 28: core::iter::traits::iterator::Iterator::fold at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/iter/traits/iterator.rs:2004 29: <rayon::iter::fold::FoldFolder<C,ID,F> as rayon::iter::plumbing::Folder<T>>::consume_iter at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/fold.rs:158 30: <rayon::iter::while_some::WhileSomeFolder<C> as rayon::iter::plumbing::Folder<core::option::Option<T>>>::consume_iter at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/while_some.rs:139 31: <rayon::iter::map::MapFolder<C,F> as rayon::iter::plumbing::Folder<T>>::consume_iter at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/map.rs:248 32: <rayon::iter::map_with::MapWithFolder<C,U,F> as rayon::iter::plumbing::Folder<T>>::consume_iter at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/map_with.rs:322 33: rayon::iter::plumbing::Producer::fold_with at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/plumbing/mod.rs:110 34: rayon::iter::plumbing::bridge_producer_consumer::helper at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/plumbing/mod.rs:438 35: rayon::iter::plumbing::bridge_producer_consumer::helper::{{closure}} at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.3.0/src/iter/plumbing/mod.rs:427 36: rayon_core::join::join_context::call_b::{{closure}} at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/join/mod.rs:130 37: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::call::{{closure}} at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs:113 38: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panic.rs:318 39: std::panicking::try::do_call at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panicking.rs:303 40: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:86 41: std::panicking::try at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panicking.rs:281 42: std::panic::catch_unwind at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/panic.rs:394 43: rayon_core::unwind::halt_unwinding at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/unwind.rs:17 44: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs:119 45: rayon_core::job::JobRef::execute at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/job.rs:59 46: rayon_core::registry::WorkerThread::execute at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:681 47: rayon_core::registry::WorkerThread::wait_until_cold at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:665 48: rayon_core::registry::WorkerThread::wait_until at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:639 49: rayon_core::registry::main_loop at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:759 50: rayon_core::registry::ThreadBuilder::run at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:56 51: <rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{{closure}} at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.7.0/src/registry.rs:101 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. fatal runtime error: failed to initiate panic, error 42381904 qemu: uncaught target signal 6 (Aborted) - core dumped
</details>
plicease commented on Issue #1716:
might be related #1774?
cfallin commented on Issue #1716:
Hi, sorry, I missed this issue previously; #1774 (which I just merged) should fix this. I don't have your precise test-case handy; please let us know if it still fails and I can investigate further!
plicease commented on Issue #1716:
:tada: works thanks!
plicease closed Issue #1716:
- What are the steps to reproduce the issue?
- Adjust the multi.c example that comes with wasmtime #1715
- compile and run on aarch64
pi1% env RUST_BACKTRACE=1 ./a.out Initializing... Compiling module... thread '<unnamed>' panicked at 'not implemented', cranelift/codegen/src/isa/aarch64/abi.rs:1203:18 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1063 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204 9: std::panicking::default_hook at src/libstd/panicking.rs:224 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:470 11: std::panicking::begin_panic 12: cranelift_codegen::isa::aarch64::lower::lower_insn_to_regs 13: cranelift_codegen::machinst::lower::Lower<I>::lower 14: cranelift_codegen::machinst::compile::compile 15: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::machinst::MachBackend>::compile_function 16: cranelift_codegen::context::Context::compile 17: cranelift_codegen::context::Context::compile_and_emit 18: wasmtime_jit::compiler::make_trampoline 19: wasmtime_jit::compiler::Compiler::compile 20: wasmtime_jit::instantiate::CompiledModule::new 21: wasmtime::module::Module::from_binary_unchecked 22: wasmtime::module::Module::from_binary 23: wasmtime_module_new 24: main 25: __libc_start_main 26: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. fatal runtime error: failed to initiate panic, error 3705270992 Abort (core dumped)
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?Expect the program to run without fail as it does on x86_64. If multi_value isn't supported on aarch64 I'd expect the config option to fail (although I note that it doesn't have a return value). I did do a search on github issues and PRs for multi values and I didn't see anything relevant so I wasn't 100% sure if this just wasn't supported yet or ever.
- Which Wasmtime version / commit hash / branch are you using?
This is 0.16.0, bit I've seen it in dev versions including the 8f2d442. I'm using the binaries from the github releases tab.
- If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)Raspberry Pi Ubuntu Focal
pi1% uname -a Linux pi1 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I originally saw this in my CI for perl Wasm bindings:
https://github.com/perlwasm/Wasm/issues/58
But only just now verified that I could reproduce from the wasmtime example.
Last updated: Dec 23 2024 at 12:05 UTC