-
Notifications
You must be signed in to change notification settings - Fork 11.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
llvm-objdump emits <unknown> and wrong register names when using "smc" and "TTBR0_EL2" on arm64(aarch64) #53956
Comments
@llvm/issue-subscribers-backend-aarch64 |
@llvm/issue-subscribers-tools-llvm-objdump |
I believe this started with https://reviews.llvm.org/D110065. I think because these are not present on R profile and llvm-objdump doesn't know to default to A profile? Adding the v8a feature or selecting a cpu works around it, which supports that idea:
@labrinea Does that sound right to you? |
Actually, I'm writing a bare-metal program for AArch64 with Rust, it becomes not been able to compile recently. // test.rs
#![no_std]
#[no_mangle]
fn test() {
use core::arch::asm;
unsafe {
asm!("smc 0", clobber_abi("C"));
asm!("mrs x0, TTBR0_EL2");
}
} this code can compile with nightly-2022-02-17, but it cannot with nightly-2022-02-18 and emits errors like below. $ rustup run nightly-2022-02-18 rustc --target aarch64-unknown-none --crate-type=lib test.rs
error: instruction requires: el3
--> test.rs:7:15
|
7 | asm!("smc 0", clobber_abi("C"));
| ^
|
note: instantiated into assembly here
--> <inline asm>:1:2
|
1 | smc 0
| ^
error: expected readable system register
--> test.rs:8:15
|
8 | asm!("mrs x0, TTBR0_EL2");
| ^
|
note: instantiated into assembly here
--> <inline asm>:1:10
|
1 | mrs x0, TTBR0_EL2
| ^
error: aborting due to 2 previous errors The version information of nightly-2022-02-17 and nightly-2022-02-18 show that the LLVM version switched to 14. $ rustup run nightly-2022-02-17 rustc --version --verbose
rustc 1.60.0-nightly (75d9a0ae2 2022-02-16)
binary: rustc
commit-hash: 75d9a0ae210dcd078b3985e3550b59064e6603bc
commit-date: 2022-02-16
host: x86_64-unknown-linux-gnu
release: 1.60.0-nightly
LLVM version: 13.0.0
$ rustup run nightly-2022-02-18 rustc --version --verbose
rustc 1.60.0-nightly (30b3f35c4 2022-02-17)
binary: rustc
commit-hash: 30b3f35c420694a4f24e5a4df00f06073f4f3a37
commit-date: 2022-02-17
host: x86_64-unknown-linux-gnu
release: 1.60.0-nightly
LLVM version: 14.0.0 Therefore, I suspect the rust's compile error is caused by LLVM 14 and continued to inspect, I finally found this objdump's issue. Thanks to #53956 (comment), I came up with an idea to add "features: +v8.1a" to target triple configure file and the above source code can compile now.
I think it affects not only llvm-objdump but also the build system of rust. I'm not clear on whether this behavior is a bug or a specification. If it is a spec, I must change my configure files. Anyway, #53956 (comment) helps me very much. |
I read the discussion and code review.
Based on the above sentence, I think the behavior of "llvm-objdump" should be repaired. I think it may be ok to fix only by reverting line 523 in clang/lib/Basic/Targets/AArch64.cpp, // ArchKind = llvm::AArch64::ArchKind::INVALID;
ArchKind = llvm::AArch64::ArchKind::ARMV8A; I will try it, but if anyone has any idea, please add a comment. |
A proposed patch for this. Maybe you could have a check. |
I compiled llvm 14.0.1 with this patch, and confirmed that llvm-objdump emits SMC and TTBR_EL2 correctly. |
The above patch is now landed in 4a31af8. To fix the problem in the Rust side, I will send a PR to ask them cherry-pick this patch. |
Closing as the fix is now merged in rust-lang/rust#98285. |
When I disassembly the aarch64 binary containg "smc 0" and "mrs x0, TTBR0_EL2", I found the result of "llvm-objdump -d " are different between llvm13 and llvm14.
llvm14-objdump emits "smc 0" as "<unknown>", and " mrs x0, TTBR0_EL2" as "mrs x0, S3_4_C2_C0_0".
llvm13-objdump seems printing correctly.
Test Code
LLVM Version
I installed llvm 13 and 14 from https://apt.llvm.org/ on ubuntu.
Compile Command
Result
The text was updated successfully, but these errors were encountered: