Open jonathanpallant opened 4 months ago
The same issue happens with riscv32imac-unknown-none-elf
, when trying to use the "A" extension in global_asm!
, so this does not seem to be an issue with a specific target, but rather how rustc
handles target features for global_asm!
. Adding .option arch, rv32imac
makes the error go away.
$ cargo build --release
Compiling qemu-armv7r v0.1.0 (/Users/chrisnc/src/armv7r-issues)
error: <inline asm>:7:5: instruction requires the following: 'A' (Atomic Instructions)
lr.w t0, 0(t1)
^
minimized:
#![no_std]
core::arch::global_asm!(
r#"
.section .text.startup
.global _start
.code 32
.align 0
_start:
vmsr fpexc, r0
"#
);
works: 'rustc --edition=2021 --crate-type lib --target armv7r-none-eabihf repro.rs -C opt-level=0 -C embed-bitcode=no' fails: 'rustc --edition=2021 --crate-type lib --target armv7r-none-eabihf repro.rs -C opt-level=0' fails: 'rustc --edition=2021 --crate-type lib --target armv7r-none-eabihf repro.rs -C opt-level=s -C embed-bitcode=no'
so both opt-level
and embed-bitcode=no
affect it. huh
I have a half-baked (read: totally uninformed goose chase) that LLVM might not be properly copying the target features when creating the TargetMachine codegen.
Following this down:
The last one says:
// SAFETY: llvm::LLVMRustCreateTargetMachine copies pointed to data
But:
doesn't do the copying. I'm trying to hunt down where in LLVM this copy would actually take place, in the createTargetMachine code.
@Dirbaio tried leaking the feature flags, so it's probably not the "llvm doesn't copy the data right" thing I was guessing. Leaving the breadcrumbs in case it's useful for anyone following the codegen process down.
This is possibly a dupe of https://github.com/rust-lang/rust/issues/80608
i've narrowed it to this line. If that runs, compilation fails.
so it's LTO-related, yep. Seems similar to https://github.com/rust-lang/rust/issues/80608 though the compilation does abort here. Probably root cause is https://github.com/llvm/llvm-project/issues/61991 too.
narrowed it down to https://github.com/rust-lang/llvm-project/blob/96aca7c51701f9b3c5dd8567fcddf29492008e6d/llvm/lib/Object/ModuleSymbolTable.cpp#L96
the target features string there is empty. If I hardcode it to "+vfp3d16" the error goes away, that confirms the issue is there.
As in https://github.com/rust-lang/rust/issues/80608#issuecomment-1094267279, the workaround is to add assembly directives in the global_asm!
block to enable target features. In this case it would be .fpu vfpv3-d16
, which armv7r-none-eabihf
enables by default.
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/armv7r-unknown-none-eabihf.20weirdness/near/448803070 for discussion and https://github.com/ferrous-systems/armv7r-issues for a reproducer.
I tried this code:
In debug profile, this compiles OK. If you use release profile and force codegen-units=1, it compiles. On armv8r-unknown-none-eabihf, it compiles.
But, if the target is armv7r-unknown-none-eabihf and codegen-units != 1, you get this error:
Meta
rustc --version --verbose
:or
Both have the same issue.