-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: