Getting SIGSEGV with `-fp-armv8` features

[tnishinaga]

I'm getting SIGSEGV: invalid memory reference crashes when compiling projects with -fp-armv8 features.

I got same results on macosx and linux.

I tried this code:

codes

`src/startup.rs` ```rust #![no_std] #![no_main] #![feature(asm)] #[no_mangle] pub extern "C" fn startup() { loop { unsafe{ asm!("wfe") } }; } ``` `.cargo/config.toml` ```toml [unstable] build-std = ["core", "compiler_builtins"] build-std-features = ["compiler-builtins-mem"] [build] target = "aarch64-unknown-none.json" ``` `aarch64-unknown-none.json` ```json { "arch": "aarch64", "data-layout": "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128", "env": "", "executables": true, "features": "+strict-align,-fp-armv8", "is-builtin": true, "linker": "rust-lld", "linker-flavor": "ld.lld", "pre-link-args": { "ld.lld": ["-Tldscript.ld"] }, "llvm-target": "aarch64-unknown-none", "max-atomic-width": 128, "os": "none", "panic-strategy": "abort", "relocation-model": "static", "target-c-int-width": "32", "target-endian": "little", "target-pointer-width": "64", "unsupported-abis": [ "stdcall", "fastcall", "vectorcall", "thiscall", "win64", "sysv64" ], "vendor": "" } ``` `Cargo.toml` ```toml [package] name = "kernel" version = "0.1.0" authors = ["tnishinaga <>"] edition = "2018" [[bin]] name = "kernel" path = "src/startup.rs" [profile.dev] panic = "abort" [profile.release] panic = "abort" [dependencies] ``` `ldscript.ld` ``` OUTPUT_ARCH(aarch64) ENTRY(_start) MEMORY { /* for qemu(256MiB) */ /* entry point is 0x40000000 */ RAM(xrw) : ORIGIN = 0x40080000 , LENGTH = 0x10000000 - 0x00080000 } SECTIONS { .text : { __text_start = .; __start = .; KEEP(*(.text.start)) KEEP(*(.text.exeption.el2)) *(.text*) . = ALIGN(4096); __text_end = .; } > RAM .rodata : { __rodata_start = .; *(.rodata*) . = ALIGN(4096); __rodata_end = .; } > RAM .data : { __data_start = . ; *(.data*) . = ALIGN(4096); __data_end = . ; } > RAM .bss : { __bss_start = . ; *(.bss*) . = ALIGN(4096); __bss_end = . ; } > RAM /* 8MiB space for heap memory */ . = . + (1024 * 1024) * 8; __stack_end = .; /* 8MiB space */ __stack_start = __stack_end + (1024 * 1024) * 8; /* /DISCARD/ : { *(.debug*) } */ } ```

I expected to see this happen: build sccuess

Instead, this happened: SIGSEGV: invalid memory reference

Meta

macosx

rustc --version --verbose:

rustc 1.50.0-nightly (1f5bc176b 2020-12-19)
binary: rustc
commit-hash: 1f5bc176b0e54a8e464704adcd7e571700207fe9
commit-date: 2020-12-19
host: x86_64-apple-darwin
release: 1.50.0-nightly

Error log(on macos)

``` $ RUST_BACKTRACE=1 cargo +nightly build --target=aarch64-unknown-none.json Blocking waiting for file lock on build directory Compiling core v0.0.0 (/Users/tnishinaga/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core) Compiling rustc-std-workspace-core v1.99.0 (/Users/tnishinaga/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-core) error: could not compile `core` Caused by: process didn't exit successfully: `rustc --crate-name core --edition=2018 /Users/tnishinaga/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C panic=abort -C embed-bitcode=no -C debuginfo=2 -C metadata=0e695d8bdba0e0fe -C extra-filename=-0e695d8bdba0e0fe --out-dir /Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps --target /Users/tnishinaga/tmp/kernel/aarch64-unknown-none.json -Z force-unstable-if-unmarked -L dependency=/Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps -L dependency=/Users/tnishinaga/tmp/kernel/target/debug/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference) warning: build failed, waiting for other jobs to finish... error: build failed ```

linux

rustc +nightly --version --verbose:

rustc 1.50.0-nightly (c609b2eaf 2020-12-20)
binary: rustc
commit-hash: c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9
commit-date: 2020-12-20
host: x86_64-unknown-linux-gnu
release: 1.50.0-nightly

[tnishinaga]

Sorry, I forgot to add backtrace.

error log on lldb

``` ~/t/kernel ❯❯❯ lldb cargo ✘ 101 (lldb) target create "cargo" Current executable set to 'cargo' (x86_64). (lldb) run build --target=aarch64-unknown-none.json Process 14517 launched: '/Users/tnishinaga/.cargo/bin/cargo' (x86_64) Process 14517 stopped * thread #2, stop reason = exec frame #0: 0x0000000100eed000 dyld`_dyld_start dyld`_dyld_start: -> 0x100eed000 <+0>: popq %rdi 0x100eed001 <+1>: pushq $0x0 0x100eed003 <+3>: movq %rsp, %rbp 0x100eed006 <+6>: andq $-0x10, %rsp Target 0: (cargo) stopped. (lldb) c Process 14517 resuming Compiling core v0.0.0 (/Users/tnishinaga/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core) Compiling rustc-std-workspace-core v1.99.0 (/Users/tnishinaga/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/rustc-std-workspace-core) Compiling compiler_builtins v0.1.36 error: could not compile `core` Caused by: process didn't exit successfully: `rustc --crate-name core --edition=2018 /Users/tnishinaga/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C panic=abort -C embed-bitcode=no -C debuginfo=2 -C metadata=0e695d8bdba0e0fe -C extra-filename=-0e695d8bdba0e0fe --out-dir /Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps --target /Users/tnishinaga/tmp/kernel/aarch64-unknown-none.json -Z force-unstable-if-unmarked -L dependency=/Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps -L dependency=/Users/tnishinaga/tmp/kernel/target/debug/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference) warning: build failed, waiting for other jobs to finish... Process 14517 stopped * thread #3, stop reason = signal SIGUSR1 frame #0: 0x00007fff72696062 libsystem_kernel.dylib`__psynch_mutexwait + 10 libsystem_kernel.dylib`__psynch_mutexwait: -> 0x7fff72696062 <+10>: jae 0x7fff7269606c ; <+20> 0x7fff72696064 <+12>: movq %rax, %rdi 0x7fff72696067 <+15>: jmp 0x7fff72694629 ; cerror_nocancel 0x7fff7269606c <+20>: retq Target 0: (cargo) stopped. ```

backtrace

``` (lldb) bt * thread #3, stop reason = signal SIGUSR1 * frame #0: 0x00007fff72696062 libsystem_kernel.dylib`__psynch_mutexwait + 10 frame #1: 0x00007fff72754917 libsystem_pthread.dylib`_pthread_mutex_firstfit_lock_wait + 83 frame #2: 0x00007fff72752937 libsystem_pthread.dylib`_pthread_mutex_firstfit_lock_slow + 222 frame #3: 0x00007fff727574b9 libsystem_pthread.dylib`_pthread_cond_wait + 846 frame #4: 0x000000010089383e cargo`jobserver::HelperState::for_each_request::hd7676203155a2e1f + 478 frame #5: 0x0000000100893bac cargo`std::sys_common::backtrace::__rust_begin_short_backtrace::h8fcdd033f1d0a3b3 + 60 frame #6: 0x000000010089470e cargo`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::he7c0c0a7015d0f87 + 142 frame #7: 0x00000001008df98d cargo`std::sys::unix::thread::Thread::new::thread_start::h93dd3097fa4fa219 + 45 frame #8: 0x00007fff72757109 libsystem_pthread.dylib`_pthread_start + 148 frame #9: 0x00007fff72752b8b libsystem_pthread.dylib`thread_start + 15 ```

[camelid]

Maybe a cargo bug based on the backtrace?

[camelid]

@tnishinaga Can you please provide some sample code that reproduces this crash? Never mind, I missed it in your issue description. Sorry about that!

@rustbot label -E-needs-mcve

[tnishinaga]

Maybe a cargo bug based on the backtrace?

Sorry, I have a mistake. It may not be cargo bug.

I have retaken the rustc backtrace on my environment.

rustc backtrace on lldb

``` ~/t/kernel ❯❯❯ lldb rustc (lldb) target create "rustc" Current executable set to 'rustc' (x86_64). (lldb) run --crate-name core --edition=2018 /Users/tnishinaga/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C panic=abort -C embed-bitcode=no -C debuginfo=2 -C metadata=0e695d8bdba0e0fe -C extra-filename=-0e695d8bdba0e0fe --out-dir /Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps --target /Users/tnishinaga/tmp/kernel/aarch64-unknown-none.json -Z force-unstable-if-unmarked -L dependency=/Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps -L dependency=/Users/tnishinaga/tmp/kernel/target/debug/deps --cap-lints allow Process 14891 launched: '/Users/tnishinaga/.cargo/bin/rustc' (x86_64) Process 14891 stopped * thread #2, stop reason = exec frame #0: 0x000000010026d000 dyld`_dyld_start dyld`_dyld_start: -> 0x10026d000 <+0>: popq %rdi 0x10026d001 <+1>: pushq $0x0 0x10026d003 <+3>: movq %rsp, %rbp 0x10026d006 <+6>: andq $-0x10, %rsp Target 0: (rustc) stopped. (lldb) c Process 14891 resuming {"artifact":"/Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps/core-0e695d8bdba0e0fe.d","emit":"dep-info"} {"artifact":"/Users/tnishinaga/tmp/kernel/target/aarch64-unknown-none/debug/deps/libcore-0e695d8bdba0e0fe.rmeta","emit":"metadata"} Process 14891 stopped * thread #8, stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffffe) frame #0: 0x00000001017c8bf8 librustc_driver-232461863c811c0c.dylib`llvm::LegalizerInfo::findAction(std::__1::vector, std::__1::allocator > > const&, unsigned int) + 120 librustc_driver-232461863c811c0c.dylib`llvm::LegalizerInfo::findAction: -> 0x1017c8bf8 <+120>: movb 0x2(%r14,%rcx), %dil 0x1017c8bfd <+125>: movzbl %dil, %ecx 0x1017c8c01 <+129>: leaq 0x118(%rip), %rdx ; <+416> 0x1017c8c08 <+136>: movslq (%rdx,%rcx,4), %rcx Target 0: (rustc) stopped. (lldb) bt * thread #8, stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffffe) * frame #0: 0x00000001017c8bf8 librustc_driver-232461863c811c0c.dylib`llvm::LegalizerInfo::findAction(std::__1::vector, std::__1::allocator > > const&, unsigned int) + 120 frame #1: 0x00000001017c79d3 librustc_driver-232461863c811c0c.dylib`llvm::LegalizerInfo::findScalarLegalAction(llvm::InstrAspect const&) const + 483 frame #2: 0x00000001017c7f9f librustc_driver-232461863c811c0c.dylib`llvm::LegalizerInfo::getAction(llvm::LegalityQuery const&) const + 239 frame #3: 0x00000001017c8344 librustc_driver-232461863c811c0c.dylib`llvm::LegalizerInfo::getAction(llvm::MachineInstr const&, llvm::MachineRegisterInfo const&) const + 852 frame #4: 0x00000001017a2c24 librustc_driver-232461863c811c0c.dylib`llvm::LegalizerHelper::legalizeInstrStep(llvm::MachineInstr&) + 148 frame #5: 0x000000010179ec97 librustc_driver-232461863c811c0c.dylib`llvm::Legalizer::legalizeMachineFunction(llvm::MachineFunction&, llvm::LegalizerInfo const&, llvm::ArrayRef, llvm::LostDebugLocObserver&, llvm::MachineIRBuilder&) + 1671 frame #6: 0x000000010179fe30 librustc_driver-232461863c811c0c.dylib`llvm::Legalizer::runOnMachineFunction(llvm::MachineFunction&) + 816 frame #7: 0x0000000101bc477d librustc_driver-232461863c811c0c.dylib`llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 285 frame #8: 0x0000000102556ef8 librustc_driver-232461863c811c0c.dylib`llvm::FPPassManager::runOnFunction(llvm::Function&) + 1064 frame #9: 0x000000010255c933 librustc_driver-232461863c811c0c.dylib`llvm::FPPassManager::runOnModule(llvm::Module&) + 67 frame #10: 0x0000000102557459 librustc_driver-232461863c811c0c.dylib`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 937 frame #11: 0x0000000100912dc2 librustc_driver-232461863c811c0c.dylib`LLVMRustWriteOutputFile + 722 frame #12: 0x00000001008397ec librustc_driver-232461863c811c0c.dylib`rustc_codegen_llvm::back::write::write_output_file::hc91f3ead66ce99ac + 364 frame #13: 0x000000010083e794 librustc_driver-232461863c811c0c.dylib`rustc_codegen_llvm::back::write::codegen::h5fbc5674fe655c46 + 5172 frame #14: 0x000000010085ba9f librustc_driver-232461863c811c0c.dylib`rustc_codegen_ssa::back::write::finish_intra_module_work::h7952582946c0a789 + 223 frame #15: 0x0000000100855d73 librustc_driver-232461863c811c0c.dylib`rustc_codegen_ssa::back::write::execute_work_item::h643b74baadb55b95 + 3267 frame #16: 0x000000010078429f librustc_driver-232461863c811c0c.dylib`std::sys_common::backtrace::__rust_begin_short_backtrace::hccecd38fee239049 + 159 frame #17: 0x0000000100785b88 librustc_driver-232461863c811c0c.dylib`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h435cab2a972e42f7 + 168 frame #18: 0x000000010807b75d libstd-cf45c391193686b0.dylib`std::sys::unix::thread::Thread::new::thread_start::h93dd3097fa4fa219 + 45 frame #19: 0x00007fff72757109 libsystem_pthread.dylib`_pthread_start + 148 frame #20: 0x00007fff72752b8b libsystem_pthread.dylib`thread_start + 15 ```

Let me know if you need anything else.

[LeSeulArtichaut]

Thanks @tnishinaga for the helpful info. So I guess now it looks like an LLVM issue?

Also, I assume the asm!() is needed for the repro?

[tnishinaga]

Also, I assume the asm!() is needed for the repro?

I got same error without asm!() code. So I assume asm!() is not needed for the reproduce.

[LeSeulArtichaut]

@rustbot ping llvm

[rustbot]

Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some instructions for tackling these sorts of bugs. Maybe take a look? Thanks! <3

cc @camelid @comex @cuviper @DutchGhost @hdhoang @heyrutvik @higuoxing @JOE1994 @jryans @mmilenko @nagisa @nikic @Noah-Kennedy @SiavoshZarrasvand @spastorino @vertexclique

[apiraino]

Assigning P-medium as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[nagisa]

I wouldn't be surprised if there's some assumption somewhere in the LLVM backend that aarch64 implies floating point support at hardware level. Which then in turn is making some assertion fail, which in your case manifests itself as a SIGSEGV.

[Amanieu]

rustc: /home/amanieu/code/rust/src/llvm-project/llvm/lib/CodeGen/GlobalISel/LegalizerInfo.cpp:573:
static llvm::LegalizerInfo::SizeAndAction llvm::LegalizerInfo::findAction(const SizeAndActionsVec&, uint32_t): Assertion `It != Vec.begin() && "Does Vec not start with size 1?"' failed.

Trying to reduce...

[Amanieu]

Found a different crash while trying to reduce. This seems to be a regression in LLVM 12.

define float @foo(double %x) {
start:
  %0 = fptrunc double %x to float
  ret float %0
}

$ build/x86_64-unknown-linux-gnu/llvm/bin/llc -march=aarch64 -global-isel=1 -O0 -mattr=-fp-armv8 test.ll                      
llc: /home/amanieu/code/rust/src/llvm-project/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp:950: void llvm::MachineIRBuilder::validateTruncExt(llvm::LLT, llvm::LLT, bool): Assertion `DstTy.getSizeInBits() > SrcTy.getSizeInBits() && "invalid narrowing extend"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.  Program arguments: build/x86_64-unknown-linux-gnu/llvm/bin/llc -march=aarch64 -global-isel=1 -O0 -mattr=-fp-armv8 test.ll
1.  Running pass 'Function Pass Manager' on module 'test.ll'.
2.  Running pass 'IRTranslator' on function '@foo'
 #0 0x0000563892935add llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x28f4add)
 #1 0x00005638929336f4 llvm::sys::RunSignalHandlers() (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x28f26f4)
 #2 0x0000563892933863 SignalHandler(int) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x28f2863)
 #3 0x00007fb774fbe960 __restore_rt (/usr/lib/libpthread.so.0+0x13960)
 #4 0x00007fb774ab0ef5 raise (/usr/lib/libc.so.6+0x3cef5)
 #5 0x00007fb774a9a862 abort (/usr/lib/libc.so.6+0x26862)
 #6 0x00007fb774a9a747 _nl_load_domain.cold (/usr/lib/libc.so.6+0x26747)
 #7 0x00007fb774aa9646 (/usr/lib/libc.so.6+0x35646)
 #8 0x0000563892eecd20 llvm::MachineIRBuilder::validateSelectOp(llvm::LLT, llvm::LLT, llvm::LLT, llvm::LLT) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x2eabd20)
 #9 0x0000563892eed0b3 llvm::MachineIRBuilder::buildInstr(unsigned int, llvm::ArrayRef<llvm::DstOp>, llvm::ArrayRef<llvm::SrcOp>, llvm::Optional<unsigned int>) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x2eac0b3)
#10 0x0000563890afca5f llvm::AArch64CallLowering::lowerReturn(llvm::MachineIRBuilder&, llvm::Value const*, llvm::ArrayRef<llvm::Register>, llvm::FunctionLoweringInfo&, llvm::Register) const (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0xabba5f)
#11 0x0000563892e82a57 llvm::IRTranslator::translateRet(llvm::User const&, llvm::MachineIRBuilder&) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x2e41a57)
#12 0x0000563892e90044 llvm::IRTranslator::runOnMachineFunction(llvm::MachineFunction&) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x2e4f044)
#13 0x0000563891c75a0c llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x1c34a0c)
#14 0x000056389210b6d0 llvm::FPPassManager::runOnFunction(llvm::Function&) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x20ca6d0)
#15 0x000056389210c211 llvm::FPPassManager::runOnModule(llvm::Module&) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x20cb211)
#16 0x000056389210b033 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x20ca033)
#17 0x00005638907aaed7 main (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x769ed7)
#18 0x00007fb774a9bb25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#19 0x0000563890847cae _start (build/x86_64-unknown-linux-gnu/llvm/bin/llc+0x806cae)

[Amanieu]

• https://bugs.llvm.org/show_bug.cgi?id=48825
• https://bugs.llvm.org/show_bug.cgi?id=45721 (though not an exact match)

[nasherm]

@rustbot claim