Testing w/qemu?

When testing the compiler via x.py test ... for a cross-build arch I see many failures like the one below. ENOEXEC / Exec format error is presumably because we're trying to execute a just-built test case for the target architecture. Presumably I could make these tests work if I could convince the test suite to execute them using qemu-hexagon.

What's the Right Way to enable this? I've set the qemu-rootfs in the config.toml but I wouldn't expect this to be sufficient on its own to run the test via QEMU. Is there a configuration option somewhere that I can use? Or do I need to use binfmt-misc - maybe there's a chain of exec'd programs? Setting CARGO_TARGET_HEXAGON_UNKNOWN_LINUX_MUSL_RUNNER to point to qemu-hexagon was not effective either.

executing cd "/local/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/test/ui/abi/cabi-int-widening" && RUST_TEST_THREADS="16" "/l
ocal/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/test/ui/abi/cabi-int-widening/a"
thread '[ui] tests/ui/abi/cabi-int-widening.rs' panicked at src/tools/compiletest/src/runtest.rs:2327:33:
failed to exec `cd "/local/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/test/ui/abi/cabi-int-widening" && LD_LIBRARY_PATH="/local/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/hexagon-unknown-linux-musl/lib:/local/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/test/ui/abi/cabi-int-widening/auxiliary:/local/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/local/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/stage0/lib" RUST_TEST_THREADS="16" "/local/mnt/workspace/hex/rust/build/x86_64-unknown-linux-gnu/test/ui/abi/cabi-int-widening/a"`: Os { code: 8, kind: Uncategorized, message: "Exec format error" }
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: <compiletest::runtest::TestCx>::compose_and_run
   3: <compiletest::runtest::TestCx>::exec_compiled_test_general
   4: <compiletest::runtest::TestCx>::run_revision
   5: compiletest::runtest::run
   6: <compiletest::make_test_closure::{closure#0} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Setting qemu-rootfs should be sufficient to tell it that you want to run under an emulator. Can you confirm that it is set in the correct table for your target?

Also, the set of supported qemu targets is hard-coded here and here (and possibly other places).

Does that mean in the definitions in compiler/rustc_target/src/spec/targets/hexagon_unknown_linux_musl.rs ?

Also, the set of supported qemu targets is hard-coded here and here (and possibly other places).

Ok -- the remote-test-client isn't what I thought I was looking for, but maybe I should have. I assumed we wouldn't need to boot a whole guest OS in order to run some of these test cases but maybe that's wrong. I was hoping we could use linux userspace emulation to run some of these tests.

I'll take a closer look at the remote-test-client logic, thanks.

No, in config.toml, make sure you haven't made a typo. For example:

[target.hexagon-unknown-linux-musl]
qemu-rootfs = "..."

oh...heh, heh..tsk.

Sorry - it was commented out. smh.

Anyways - thanks for the suggestion and now I see remote-test-client failing where you indicated. So I think we can figure out a way to get the tests running.

Oh - it appears that a ~somewhat recent update provides a runner config option that's perfectly suited for this.

1 Like