@Afonso Bordado you might be interested in the fact that riscv64 is failing CI with a rustc 1.70 build (which notably contains a LLVM 15->16 upgrade relative to 1.69). I can reproduce this failure locally with ./ci/run-tests.sh
using the same version of QEMU as CI. Additionally I get a segfault in QEMU using QEMU 7.2.3 and 8.0.2 (current latest according to their website)
Do you perhaps have actual hardware to test on? I dunno how to get a gdb stack trace from qemu user mode
That's weird. Yeah I can try this on actual hardware tommorow. Might need some help with tracking it down afterwards though.
hm ok so I don't know how accurate this is but I used gdb-multiarch
locally to attach to qemu and it reports the faulting instruction is ld a0,0(s0)
within _ZN5tokio7runtime9scheduler12multi_thread4park6Parker8shutdown17h7a55a0112c28a19dE
where s0
is null
so this may be "just" an llvm issue
(also first time I got gdb and qemu user mode working, wow!)
turns out, not even cranelift can get away from llvm problems. :laughter_tears:
I've been having some issues running these WASM tests natively, it looks like rustup does not ship rust-lld
for riscv64. Is there a guide somewhere on how I can compile that?
Is it shipped with the llvm-tools component?
Doesen't seem to be. I tried rustup component add llvm-tools-preview
and it still doesen't show up in toolchain bin directory
afonso@starfive:~/git/wasmtime$ ls ~/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/
cargo cargo-clippy cargo-fmt clippy-driver rust-gdb rust-gdbgui rust-lldb rustc rustdoc rustfmt
I found a similar issue in the rust-lang repo: https://github.com/rust-lang/rust/issues/111907
Yeah rust-lld
is only compiled for a subset of architectures since it adds build time. It's probably "just" a flag somewhere to get it into rustc's distribution, but if it's not there that flag probably isn't flipped. Otherwise though it should still be possible to do ./ci/run-tests.sh --no-run --target ...
and scp the cross-compiled binaries perhaps?
Along the lines of the s390x issue, looks like 1.71 beta may not have this issue, so may not be much to investigate
So, I've found some slightly weird results. Using rustc 1.70.0 (90c541806 2023-05-31)
which seems to be the same as on CI, I can't reproduce this natively, or in QEMU in my machine. Locally the tests run fine.
Additionally I ran the test in CI again. While originally it failed in wasi-preview1-host-in-preview2
, it looks like in the latest run it now failed in wasi-http
. (neither one crashes natively or on QEMU in my machine).
I also ran a CI run with 1.71 beta, and it looks like its fixed as you mentioned.
Oh did you disable incremental and debuginfo and enable optimizations locally?
CI is a bit funky in that regard
Huh, I didn't know we did that. I'll try that again at least as a sanity check that my setup is working
Afonso Bordado said:
afonso@starfive:~/git/wasmtime$ ls ~/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/ cargo cargo-clippy cargo-fmt clippy-driver rust-gdb rust-gdbgui rust-lldb rustc rustdoc rustfmt
(note that this is not where rust-lld
would be located, but somewhere like ~/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/lib/rustlib/riscv64gc-unknown-linux-gnu/bin/
but I don't believe it's distributed for that target yet)
Last updated: Dec 23 2024 at 12:05 UTC