rustc crashing over illegal instruction

[ebtaleb]

rustc killed by SIGILL. It is caused by a mfence instruction that belongs to the SSE2 instruction set. Sadly, my 10-year-old CPU does not support SSE2.

⇒  ./rustc -v 
rustc 0.11.0-pre-nightly (6b1426b 2014-05-25 01:11:19 -0700)
host: i686-unknown-linux-gnu

⇒  cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model       : 10
model name  : AMD Sempron(tm)  3000+
stepping    : 0
cpu MHz     : 1991.380
cache size  : 512 KB
fdiv_bug    : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 1
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips    : 3982.76
clflush size    : 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts

⇒  cat hw.rs 
fn main() {
    println!("hello world!");
}

⇒  ./rustc hw.rs 
[1]    7033 illegal hardware instruction  ./rustc hw.rs

(gdb) run ~/hw.rs 
Starting program: /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/rustc ~/hw.rs
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[New Thread 0xb3bff8c0 (LWP 3767)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb3bff8c0 (LWP 3767)]
0xb7028bc0 in llvm::sys::MemoryFence() () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
(gdb) bt
#0  0xb7028bc0 in llvm::sys::MemoryFence() () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#1  0xb706011a in llvm::llvm_start_multithreaded() () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#2  0xb6ef6534 in LLVMStartMultithreaded () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#3  0xb58871fe in middle::trans::base::trans_crate::closure.62375 () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#4  0xb4870316 in one::Once::doit::h9fe40ba418d51284ZIb::v0.11.0.pre () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/./libsync-305341d2-0.11.0-pre.so
#5  0xb588453c in middle::trans::base::trans_crate::hbc3d1a77adf07aac5gq::v0.11.0.pre ()
   from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#6  0xb60110e9 in driver::driver::phase_4_translate_to_llvm::h2915b3b27d3b85f7Zdk::v0.11.0.pre ()
   from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#7  0xb60080e8 in driver::driver::compile_input::hf0649dd005bd9326AVj::v0.11.0.pre () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#8  0xb60c937a in driver::run_compiler::h06f4471c3444d27fvym::v0.11.0.pre () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#9  0xb60c679c in driver::main_args::closure.93521 () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#10 0xb60d9dfb in driver::monitor::closure.94592 () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#11 0xb60d5706 in task::TaskBuilder::try::closure.94355 () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/librustc-d252d482-0.11.0-pre.so
#12 0xb7faae28 in task::spawn_opts::closure.7802 () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/libnative-1fb5e2c0-0.11.0-pre.so
#13 0xb527eb19 in rt::task::Task::run::closure.25254 () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/libstd-59beb4f7-0.11.0-pre.so
#14 0xb5283e04 in rt::unwind::Unwinder::try::try_fn::hf1a154dc31c8998b5gy::v0.11.0.pre ()
   from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/libstd-59beb4f7-0.11.0-pre.so
#15 0xb52e4603 in rust_try () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/libstd-59beb4f7-0.11.0-pre.so
#16 0xb527ea7c in rt::task::Task::run::h01f4e25c4b3762751dw::v0.11.0.pre () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/libstd-59beb4f7-0.11.0-pre.so
#17 0xb7faac89 in task::spawn_opts::closure.7774 () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/libnative-1fb5e2c0-0.11.0-pre.so
#18 0xb528295c in rt::thread::thread_start::h9551b7fdc6124171zXw::v0.11.0.pre () from /home/jmbto/Desktop/rust-nightly-i686-unknown-linux-gnu/bin/../lib/libstd-59beb4f7-0.11.0-pre.so
#19 0xb4fdbed9 in start_thread (arg=0xb3bff8c0) at pthread_create.c:312
#20 0xb50dc2be in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

(gdb) x/i $eip
=> 0xb7028bc0 <_ZN4llvm3sys11MemoryFenceEv>:    mfence 

[emberian]

It's dying in LLVM, there's nothing we can really do about it on our side. However, LLVM's build system shouldn't be generating SSE instructions on 32-bit...

[thestinger]

I can't reproduce this. Is it still an issue? Rust generates code for the baseline architecture by default.

[rmathew]

I can reproduce this on an old Pentium 3 box - in my case the latest nightly, the latest release (0.12.0), the latest stage0 snapshot (2014-10-04 749ff5e linux-i386) all fail right away with an "Illegal Instruction" error (and it happens to be mfence as seen in GDB).

An old stage0 snapshot (2013-12-27 a5fa1d9 linux-i386) doesn't have this issue. (However, I can't build Rust right now from the sources since I'm on GCC 4.6.4 and LLVM needs GCC 4.7+.)

[rmathew]

Last stage0 snapshot that works: 2014-07-17 9fc8394
First stage0 snapshot that does not work: 2014-08-07 12e0f72

AFAICT, these correspond to the following builds respectively:
Build #10: 2014-07-17 9fc8394
Build #12: 2014-08-07 12e0f72

Using GCC 4.9.1 and the (last working) stage0 snapshot from 2014-07-17, I tried compiling the 0.12.0 release, but that fails:

rustc: i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/libcore
/home/rmathew/tmp/rust-0.12.0/src/libcore/kinds.rs:24:20: 24:22 error: expected `;` but found `as`
/home/rmathew/tmp/rust-0.12.0/src/libcore/kinds.rs:24 pub use self::Sync as Share;
                                                                        ^~
make: *** [i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.core] Error > 101

Looks like we currently need a bleeding-edge stage0 rustc snapshot to even be able to compile the latest Rust release, but such a snapshot doesn't run on older hardware. 😢

[rmathew]

Related Issue: #24668
The problem is still present in the 1.1.0 release-binaries (mfence usage in llvm::sys::MemoryFence()).
Can the build-slaves (presumably running on an x86-64 box) be configured to generate binaries for a "pure" i686-unknown-linux-gnu target?

[MagaTailor]

If a working stable snapshot were provided this once it should be enough to compile the next stable and so on.

So unless it's not technically possible, please provide a baseline x86 version for all the nostalgic people or anyone who still likes to use their old hardware.

EDIT: In retrospect, here's a few generic i686 (pentiumpro) stage0 snapshots:

https://www.dropbox.com/s/a2txw5iafxyz2eo/stage0-i686_generic-2015-08-11.tar.bz2?dl=0
https://www.dropbox.com/s/k9hxxascoyx0jmt/stage0-i686_generic-2015-12-18.tar.bz2?dl=0

[MagaTailor]

rust-lang/cargo#958

[MagaTailor]

After all this time it can be made to work after all, hooray!

My i686 build that should work on any PII class processor:

https://www.dropbox.com/s/1sguenpkvjmg6z2/rust-1.3.0-i686_generic-linux.tar.bz2?dl=0

or the 1.5.0 nightly from Oct, 02:

https://www.dropbox.com/s/7zl2whf1t9mbhh1/rust-1.5.0-i686_generic_linux.tar.bz2?dl=0

[ranma42]

It looks like in rust the base CPU for i686 is intentionally set to “pentium4” so that LLVM can generate SIMD instructions. This was originally justified citing the example of Clang. Although it is true that Clang uses pentium4 by default when generating code for the x86 architecture, it does not do it when the target is i686. I think it might make sense to downgrade i686 as in Clang/LLVM.
If there is need to have an x86 target with SIMD, I propose two alternative solutions:

• set the target CPU using the rustc option -C target-cpu when this is needed
• add i786 target triples (see for example and precedent, in http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=build-aux/config.sub ).

Would this be an acceptable solution?

FWIW, when currently when we compile for i686-unknown-linux-gnu, the resulting LLVM does not use SIMD, while Rust does:

$ objdump -S i686-unknown-linux-gnu/llvm/Release/bin/llc | grep 'xmm' | cut -d: -f2- | sort -u | head -n 3
$ objdump -S i686-unknown-linux-gnu/llvm/Release/bin/llc | grep 'st(' | cut -d: -f2- | sort -u | head -n 3
    d8 c1                   fadd   %st(1),%st
    d8 c9                   fmul   %st(1),%st
    d8 e4                   fsub   %st(4),%st

$ objdump -S i686-unknown-linux-gnu/stage2/lib/libstd-db5a760f.so | grep 'xmm' | cut -d: -f2- | sort -u | head -n 3
    0f 10 0a                movups (%edx),%xmm1
    0f 10 0e                movups (%esi),%xmm1
    0f 10 0f                movups (%edi),%xmm1
$ objdump -S i686-unknown-linux-gnu/stage2/lib/libstd-db5a760f.so | grep 'st(' | cut -d: -f2- | sort -u | head -n 3
$

[MagaTailor]

Yes, you've repeated the well established facts (by now).

I don't think there's much chance changing this policy so it's probably going to be up to the distros to offer a true i686 build.