-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Hello World App crashes with 'Illegal Instruction' in 32-bit environment on a 64-bit SoC #58414
Comments
Can you print the instruction that is failing and dump the registers with GDB? Does it happen when you don't specify the target-cpu? What linux distribution and architecture are you using? |
It happens even when taret-cpu is not set. Linux Distribution is OpenWRT and Procerros has Brahma53 processor module that implements ARMv8-A complaint architecture. (gdb) info all-registers (gdb) backtrace |
Ok, and when you type |
Here is the disassemble output: (gdb) disassemble Thanks! |
Ok yes, it's an old CP15 barrier, you should be fine if you just use |
Instead of using armv7-unknown-linux-gnueabihf, we opted to enable CP15 barrier emulation in the kernel and it no longer crashes. Do you see any problem with this approach? Thanks for your help! |
The float ABIs are different so if your c libraries are built with the hard float ABI you will have issues. You'll also have a less optimal Rust std library with |
CP15 barrier emulation should be enabled in the kernel if you are using CP15 barrier target. Closing. |
…rland aarch64 always has neon enabled, and thus it's not included in /proc/cpuinfo. Previously, we'd fall back to arm when running with a 32-bit userland, even though armv7 is perfectly appropriate in this case. This would then run into the issue described in rust-lang/rust#58414 with "CP15 barrier emulation". This PR fixes that.
…rland On aarch64, neon will not be present in /proc/cpuinfo, instead asimd is there. Previously, we'd fall back to arm when running with a 32-bit userland, even though armv7 is perfectly appropriate in this case. This would then run into the issue described in rust-lang/rust#58414 with "CP15 barrier emulation". This PR fixes that.
…rland On aarch64, neon will not be present in /proc/cpuinfo, instead asimd is there. Previously, we'd fall back to arm when running with a 32-bit userland, even though armv7 is perfectly appropriate in this case. This would then run into the issue described in rust-lang/rust#58414 with "CP15 barrier emulation". This PR fixes that.
…rland On aarch64, neon will not be present in /proc/cpuinfo, instead asimd is there. Previously, we'd fall back to arm when running with a 32-bit userland, even though armv7 is perfectly appropriate in this case. This would then run into the issue described in rust-lang/rust#58414 with "CP15 barrier emulation". This PR fixes that.
I am trying to build Hello World Application and run on a cortex-a53 based processor. The userspace environment is 32-bit (with the all libraries, binaries built in 32-bit mode). The Kernel however, is built in 64-bit mode.
Code:
$ cat hello.rs
fn main() {
println!("Hello World!");
}
Compile
$ rustc --target arm-unknown-linux-gnueabi -C target-cpu=cortex-a53 hello.rs
The output is that the string 'Hello World!' prints and crashes during the cleanup phase with 'illegal instruction'. gdb points to atomic_sub. I am suspecting that there is alignment issue with the memory pointers. One example of the GDB backtrace is:
gdb Backtrace
#0 atomic_sub () at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/sync/atomic.rs:2077
2077 /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/sync/atomic.rs: No such file or directory.
(gdb) quit
The text was updated successfully, but these errors were encountered: