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.

[emberian]

@petevine why do you think that? I'm the one who changed it to pentium4. I think it should be changed to something more reasonable, if pentium4 wasn't the right choice (and it looks like it wasn't: my bad).

[MagaTailor]

I spent some time and energy discussing that issue and that's what the conclusions were. The choice is not bad at all but rather the inability to easily work around it.

Even a simple suggestion of turning the stage0 snapshot into a more compliant version got ignored too, so I'm not interested in further discussing the matter.

[ranma42]

@petevine Sorry, I did not find the relevant discussion. Can you link it so that I can see what objections were raised against the two solutions I suggested?

[MagaTailor]

If you google reddit, rust users/internals and SSE2 you should get there.

In short, re the first point - won't work as you need compatible rlibs too.
Re the second one it's about compiler/benchmark performance (vectorization) and floating point IEEE 754 conformance.

Once I've demonstrated the obverse is doable (down to i586) and posted stage0 snapshots however, the last dozen interested people should be set.

It's probably too niche of a use case to expect more from the official binary distribution.

[MagaTailor]

Oh, and I had no idea this issue (unlike the other two) was still open.

[ranma42]

I found some threads about the topic, but none which put forth an analysis and comparison with Clang, nor any that proposed an actual solution. I was unable to find any PR or issue in this repository, so I opened #31110 which implements the first solution I proposed.

NB: the first solution works just fine, as the ABI does not change no matter what CPU you are targeting.
Example:

$cat testabi.rs 
#![crate_type="lib"]

pub fn add1(x: f64) -> f64 {
    x + 1.0
}
$./rust/i686-unknown-linux-gnu/stage2/bin/rustc -O --target=i686-unknown-linux-gnu -C target-cpu=pentium4 testabi.rs 
$objdump -S libtestabi.rlib 
In archive libtestabi.rlib:

testabi.0.o:     file format elf32-i386


Disassembly of section .text._ZN4add120hfa2a4733581ccd0deaaE:

00000000 <_ZN4add120hfa2a4733581ccd0deaaE>:
   0:   83 ec 0c                sub    $0xc,%esp
  13:   e8 00                   and    $0x10,%al
  15:   00 00 00 58 81 c0 03    addsd  0x0(%eax),%xmm0
  1c:   00 
  1d:   00 00 f2 0f 10          movsd  %xmm0,(%esp)
  22:   44 24 10                fldl   (%esp)
  25:   f2 0f 58                add    $0xc,%esp
  28:   80                      ret    
  29:   Address 0x0000000000000029 is out of bounds.

objdump: rust.metadata.bin: File format not recognized
objdump: testabi.0.bytecode.deflate: File format not recognized
$./rust/i686-unknown-linux-gnu/stage2/bin/rustc -O --target=i686-unknown-linux-gnu -C target-cpu=i686 testabi.rs 
$objdump -S libtestabi.rlib 
In archive libtestabi.rlib:

testabi.0.o:     file format elf32-i386


Disassembly of section .text._ZN4add120hfa2a4733581ccd0deaaE:

00000000 <_ZN4add120hfa2a4733581ccd0deaaE>:
   0:   d9 e8                   fld1   
   2:   dc 44 24 04             faddl  0x4(%esp)
   6:   c3                      ret    
objdump: rust.metadata.bin: File format not recognized
objdump: testabi.0.bytecode.deflate: File format not recognized
$

If the compiler and libraries were compiled for plain i686 (not pentium4), they would work on any i686 processor. If somebody needs some specific instructions (examples: SIMD, POPCNT, AES), it would be sufficient for them to compile their crates with appropriate options to enable those features. This can be done either by changing the target CPU (-C target-cpu=) or explicitly specifying which features should be enabled (-C target-feature=).

[MagaTailor]

No kidding? The messiah comes two years late!

ABI is not the issue here, don't muddy the waters. In the last part you've just confirmed two separate binary distributions would be necessary to not handicap SSE2 machines through rlib injection. Well done!

[ranma42]

@petevine I might be misjudging your comments, but they feel somewhat aggressive.

I do not understand your comment about SSE2 machines being handicapped by a plain i686 target.
One could say the same for every instruction set extension.
Is my machine being handicapped by rustc x86_64 because even though my CPU supports the SSSE3 and SSE4, the x86_64 target will not generate those instructions by default?
Having a target for each possible LLVM CPU feature combination is obviously impractical.
Whenever one of them is needed for a specific task, it can be activated easily by compiling with the appropriate -C target-feature= flag.

[MagaTailor]

You don't understand the details of how the rust binaries are created by the compiler, period. And now you're even mixing in amd64 which defaults to SSE2 so there's absolutely no relation cause that's what that particular ISA is about. This is my last reply in this thread.

[pnkfelix]

Moderator Note

@petevine If there was any ambiguity before as to whether your comments are "somewhat aggressive", there certainly is not any such ambiguity now.

I ask you to please review the Code of Conduct for the project: https://www.rust-lang.org/conduct.html In particular the third bullet, "Please be kind and courteous. There's no need to be mean or rude."

The sort of commenting style you are using here may be acceptable in other projects, but in general I don't want people reading these threads to be turned away from the project.

If you do not understand the moderation feedback you are receiving, please feel free to email the moderators at [email protected] to request elaboration or clarification.

[MagaTailor]

@pnkfelix You're making too much of it, I wasn't mean or rude.

Nevertheless, I feel offended by this whole affair of some random person coming in and changing everything back even though it wasn't bloody possible back in April, when I actually wanted to use Rust on a machine like that, or the OP close to two years ago!

So yeah, I feel turned away already. What do the rules say about getting banned altogether?

[alexcrichton]

We have an i586-unknown-linux-gnu target now for compiling code without SSE enabled, we're just not producing rustc nightlies for it. This is essentially status quo for other tier 3 targets, so I'm going to close this for now.

[rmathew]

@alexcrichton: Will there be regular releases or at least a
one-off build for bootstrapping for this target from the official
web-site?

[alexcrichton]

@rmathew we're regularly releasing a standard library for i586-unknown-linux-gnu but we aren't currently releasing a snapshot for that target. That means that you can compile code to run on an i586 machine but you can't run the compiler itself unless you compile it yourself from another machine.

[rmathew]

On an x86-64 machine, I compiled the released 1.8.0 version like so:

./configure --prefix=/foo/bar/rustc32 --disable-valgrind --enable-optimize \
  --enable-optimize-cxx --enable-optimize-llvm --enable-optimize-tests \
  --build=i686-unknown-linux-gnu --host=i586-unknown-linux-gnu \
  --target=i586-unknown-linux-gnu --disable-docs --disable-compiler-docs

and the binary thus built still crashes with a SIGILL on a P3 box. :-(

[alexcrichton]

@rmathew could you try and get a stack trace to see where the bad instruction is happening? We may not be handling C++ code correctly. I forget if we had build system support in 1.8.0 as well, it may have come later.

[rmathew]

$ gdb ./bin/rustc
[...]
(gdb) r --version
[...]
Program received signal SIGILL, Illegal instruction.
0xb7b4c94d in str::str.ToOwned::to_owned::h9fc80730fafb5634FVe ()
   from /extra1/rustc32/bin/../lib/libstd-db5a760f.so
(gdb) bt
#0  0xb7b4c94d in str::str.ToOwned::to_owned::h9fc80730fafb5634FVe ()
   from /extra1/rustc32/bin/../lib/libstd-db5a760f.so
#1  0xb7b42ecf in rt::lang_start::hdd382d1070c1d350rKz ()
   from /extra1/rustc32/bin/../lib/libstd-db5a760f.so
#2  0xb7fff78e in main ()
(gdb) x/i $eip
=> 0xb7b4c94d <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+141>:      movsd  0x20(%esp),%xmm0
(gdb) disassemble
Dump of assembler code for function _ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE:
   0xb7b4c8c0 <+0>:     push   %ebp
   0xb7b4c8c1 <+1>:     push   %ebx
   0xb7b4c8c2 <+2>:     push   %edi
   0xb7b4c8c3 <+3>:     push   %esi
   0xb7b4c8c4 <+4>:     sub    $0x2c,%esp
   0xb7b4c8c7 <+7>:     call   0xb7b4c8cc <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+12>
   0xb7b4c8cc <+12>:    pop    %ebx
   0xb7b4c8cd <+13>:    add    $0xd9734,%ebx
   0xb7b4c8d3 <+19>:    mov    0x48(%esp),%esi
   0xb7b4c8d7 <+23>:    test   %esi,%esi
   0xb7b4c8d9 <+25>:    js     0xb7b4c976 <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+182>
   0xb7b4c8df <+31>:    mov    $0x1,%eax
   0xb7b4c8e4 <+36>:    je     0xb7b4c8fe <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+62>
   0xb7b4c8e6 <+38>:    mov    %esi,(%esp)
   0xb7b4c8e9 <+41>:    movl   $0x1,0x4(%esp)
   0xb7b4c8f1 <+49>:    call   0xb7afd110 <__rust_allocate@plt>
   0xb7b4c8f6 <+54>:    test   %eax,%eax
   0xb7b4c8f8 <+56>:    je     0xb7b4c9b5 <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+245>
   0xb7b4c8fe <+62>:    mov    %eax,0x20(%esp)
   0xb7b4c902 <+66>:    mov    %esi,0x24(%esp)
   0xb7b4c906 <+70>:    movl   $0x0,0x28(%esp)
   0xb7b4c90e <+78>:    lea    0x20(%esp),%ecx
   0xb7b4c912 <+82>:    mov    %esi,%edx
   0xb7b4c914 <+84>:    call   0xb7b4c9e0 <_ZN3vec12Vec$LT$T$GT$7reserve20h8526356496296567822E>
   0xb7b4c919 <+89>:    mov    0x40(%esp),%edi
   0xb7b4c91d <+93>:    test   %esi,%esi
   0xb7b4c91f <+95>:    je     0xb7b4c945 <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+133>
   0xb7b4c921 <+97>:    mov    0x44(%esp),%eax
   0xb7b4c925 <+101>:   mov    0x28(%esp),%ebp
   0xb7b4c929 <+105>:   mov    0x20(%esp),%ecx
   0xb7b4c92d <+109>:   add    %ebp,%ecx
   0xb7b4c92f <+111>:   mov    %esi,0x8(%esp)
   0xb7b4c933 <+115>:   mov    %eax,0x4(%esp)
   0xb7b4c937 <+119>:   mov    %ecx,(%esp)
   0xb7b4c93a <+122>:   call   0xb7afd480 <memcpy@plt>
   0xb7b4c93f <+127>:   add    %esi,%ebp
   0xb7b4c941 <+129>:   mov    %ebp,0x28(%esp)
   0xb7b4c945 <+133>:   mov    0x28(%esp),%eax
   0xb7b4c949 <+137>:   mov    %eax,0x18(%esp)
=> 0xb7b4c94d <+141>:   movsd  0x20(%esp),%xmm0
   0xb7b4c953 <+147>:   movsd  %xmm0,0x10(%esp)
   0xb7b4c959 <+153>:   mov    0x18(%esp),%eax
   0xb7b4c95d <+157>:   mov    %eax,0x8(%edi)
   0xb7b4c960 <+160>:   movsd  0x10(%esp),%xmm0
   0xb7b4c966 <+166>:   movsd  %xmm0,(%edi)
   0xb7b4c96a <+170>:   mov    %edi,%eax
   0xb7b4c96c <+172>:   add    $0x2c,%esp
   0xb7b4c96f <+175>:   pop    %esi
   0xb7b4c970 <+176>:   pop    %edi
   0xb7b4c971 <+177>:   pop    %ebx
   0xb7b4c972 <+178>:   pop    %ebp
---Type <return> to continue, or q <return> to quit---
   0xb7b4c973 <+179>:   ret    $0x4
   0xb7b4c976 <+182>:   mov    -0xe0(%ebx),%eax
   0xb7b4c97c <+188>:   mov    %eax,(%esp)
   0xb7b4c97f <+191>:   call   0xb7afdbf0 <_ZN9panicking5panic20hcdb434c1cdedc531SaME@plt>
   0xb7b4c984 <+196>:   mov    %eax,%esi
   0xb7b4c986 <+198>:   mov    0x24(%esp),%eax
   0xb7b4c98a <+202>:   test   %eax,%eax
   0xb7b4c98c <+204>:   je     0xb7b4c9ad <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+237>
   0xb7b4c98e <+206>:   cmp    $0x1d1d1d1d,%eax
   0xb7b4c993 <+211>:   je     0xb7b4c9ad <_ZN3str11str.ToOwned8to_owned20h9fc80730fafb5634FVeE+237>
   0xb7b4c995 <+213>:   mov    0x20(%esp),%ecx
   0xb7b4c999 <+217>:   mov    %eax,0x4(%esp)
   0xb7b4c99d <+221>:   mov    %ecx,(%esp)
   0xb7b4c9a0 <+224>:   movl   $0x1,0x8(%esp)
   0xb7b4c9a8 <+232>:   call   0xb7afcec0 <__rust_deallocate@plt>
   0xb7b4c9ad <+237>:   mov    %esi,(%esp)
   0xb7b4c9b0 <+240>:   call   0xb7afe1d0 <_Unwind_Resume@plt>
   0xb7b4c9b5 <+245>:   call   0xb7afda10 <_ZN3oom3oom20h3d2cfcfffd56b89aPzbE@plt>
End of assembler dump.

[MagaTailor]

@rmathew This result is expected due to the --build=i686 you passed - follow the instructions in the reddit i586 bootstrap thread.
Edit:
This one.

[alexcrichton]

@rmathew out of curiosity, can you use the i586-unknown-linux-gnu nightlies that we're producing to run a hello world? Also, are you sure that you're running the i586 compiler instead of the i686 one by accident?

[pnkfelix]

@alexcrichton there's some amount of crosstalk in this thread, but just to be clear: can you confirm that we are supposed to be using the "Canadian cross compiler" interpretation of the build/host/target flags to configure, and thus in principle it should be unnecessary (and in some scenarios, even erroneous) to specify i586-unknown-linux-gnu for the build flag, even if today doing so (when on an i686 Linux machine) happens to sidestep other bugs?

I believe you said as much here: https://www.reddit.com/r/rust/comments/4azl1p/crossbootstrapping_a_rust_compiler_for_i586/d14usne

But I figured it would be good to confirm explicitly, especially including the term "Canadian cross" so that others can google what that means with respect to GNU configure scripts, at least for gcc

[pnkfelix]

(Ah, I did look around and rediscovered a statement from @graydon ( #2302 (comment) ) that the project originally deliberately opted not to support Canadian cross. Not sure what that entails with respect to how the build flag to configure is to be interpreted though, so my question to @alexcrichton is still open )

[MagaTailor]

@rmathew One more thing - the LLVM issue linked in that thread pertaining to your P3 has been fixed here so be sure to apply the patch. Or you can try my not so old i686 build out.

[alexcrichton]

@pnkfelix yeah you shouldn't need a form of canadian cross for rustc itself because all compilers can emit code for all targets. In that sense all you need to do is ensure that the compiler can run on your target host, in this case i586-unknown-linux-gnu.

That is, the following should suffice:

# On a "recent" machine
$ ./configure --host=i586-unknown-linux-gnu --enable-rustbuild
$ make
$ make dist

# ... transfer build/dist/rust*-i586-unknown-linux-gnu.tar.gz to target machine

# On the target "old" machine
$ ./rustc-1.10.0-dev-i586-unknown-linux-gnu/install.sh
$ ./rust-std-1.10.0-dev-i586-unknown-linux-gnu/install.sh
$ rustc -vV

(that was all typed from memory so ther emay be typos)