rustc nightly returns 1 (false) on armv7

[belst]

I tried compiling a project of mine on my raspberry pi 2 but I couldnt, because rustc always crashed.

After Investigating a bit further I found this out:

fn main() {
    println!("hello");
}

this DOES NOT compile

pi@babylon5 ~/foo/src (git)-[master] % RUST_BACKTRACE=1 rustc --verbose main.rs
1 pi@babylon5 ~/foo/src (git)-[master] % ls                                                                                                         :(
main.rs

this however, DOES compile:

fn main() {
    std::process::exit(5);
}

output:

pi@babylon5 ~/foo/src (git)-[master] % RUST_BACKTRACE=1 rustc --verbose main.rs
pi@babylon5 ~/foo/src (git)-[master] % ls
main  main.rs
pi@babylon5 ~/foo/src (git)-[master] % ./main
5 pi@babylon5 ~/foo/src (git)-[master] %                                                                                                            :(

Meta

rustc --version --verbose:

rustc 1.13.0-nightly (3c5a0fa45 2016-08-22)
binary: rustc
commit-hash: 3c5a0fa45b5e2786b6e64e27f48cd129e7aefdbd
commit-date: 2016-08-22
host: armv7-unknown-linux-gnueabihf
release: 1.13.0-nightly

uname -a:

Linux babylon5 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux

[durka]

Since it seems to be aborting with no output or backtrace, can you try running it under a debugger to see where it stops?

[belst]

(gdb) run main.rs
Starting program: /home/pi/.cargo/bin/rustc main.rs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[Inferior 1 (process 31513) exited with code 01]

[durka]

And bt doesn't give any hints?

On Thu, Aug 25, 2016 at 11:25 AM, Joshua [email protected] wrote:

(gdb) run main.rs
Starting program: /home/pi/.cargo/bin/rustc main.rs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[Inferior 1 (process 31513) exited with code 01]

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#35982 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n3Bq2QUbQ0_VTaag7fpt_SIMd_E0ks5qjbPOgaJpZM4Js8AR
.

[belst]

no stack
single stepping through gives this:

(gdb) next
Single stepping until exit from function main,
which has no line number information.
0x54dce7cc in std::rt::lang_start::hb072ea7464d45b94 ()
(gdb) next
Single stepping until exit from function _ZN3std2rt10lang_start17hb072ea7464d45b94E,
which has no line number information.
[Inferior 1 (process 31570) exited with code 01]

(gdb) bt
#0  0x54b28d34 in main ()
(gdb) next
Single stepping until exit from function main,
which has no line number information.
0x54dce7cc in std::rt::lang_start::hb072ea7464d45b94 ()
(gdb) bt
#0  0x54dce7cc in std::rt::lang_start::hb072ea7464d45b94 ()
#1  0x76e12294 in __libc_start_main (main=0x7efff5e4, argc=1995665408, argv=0x76e12250 <__libc_start_main+208>, init=<optimized out>, 
    fini=0x54df9615 <__libc_csu_fini>, rtld_fini=0x76fdf408 <_dl_fini>, stack_end=0x7efff5e4) at libc-start.c:287
#2  0x54aed04e in _start ()
(gdb) next
Single stepping until exit from function _ZN3std2rt10lang_start17hb072ea7464d45b94E,
which has no line number information.
[Inferior 1 (process 31582) exited with code 01]
(gdb) bt
No stack.
(gdb) 

[durka]

It seems like the compiler doesn't even start.

On Thu, Aug 25, 2016 at 11:31 AM, Joshua [email protected] wrote:

no stack
single stepping through gives this:

(gdb) next
Single stepping until exit from function main,
which has no line number information.
0x54dce7cc in std::rt::lang_start::hb072ea7464d45b94 ()
(gdb) next
Single stepping until exit from function _ZN3std2rt10lang_start17hb072ea7464d45b94E,
which has no line number information.
[Inferior 1 (process 31570) exited with code 01]

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#35982 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n6SF6I8cYwsX8xFOIWbkzYFCEVFfks5qjbVIgaJpZM4Js8AR
.

[belst]

well it works on the std::process::exit() example

[MagaTailor]

Did you manage to run rustc -vV? If not, look for a patchelf workaround a dozen issues earlier.

[belst]

@petevine yes. I have seen the other issue. but running rustc -vV succeeds

[MagaTailor]

Right, sorry;missed the meta info. If you're using an official build, try the workaround all the same or use a different nightly. Definitely works for me.

[belst]

just updated rustc to latest nightly

rustc 1.13.0-nightly (e9bc1bac8 2016-08-24)
binary: rustc
commit-hash: e9bc1bac8c7664fb1b487879b3fbd56221f6a721
commit-date: 2016-08-24
host: armv7-unknown-linux-gnueabihf
release: 1.13.0-nightly

still no change. stable works btw.

[MagaTailor]

Could you try a recent build of mine? If that doesn't work either, rustc is not to blame.

[belst]

your build works.

[MagaTailor]

Aha, hopefully a variation of that patchelf issue. It would be ridiculous if the buildbot binaries didn't work for some new reason!

[belst]

the patchelf workaround described in #35843 does not work and I do not get a segfault.

[MagaTailor]

Without a trace we don't even know what to add. Did you try both?

[belst]

there is no more trace than this #35982 (comment)

[nagisa]

belst: I would recommend adding a breakpoint for exit before running the program under a debugger. It might not still work if stack gets trashed, but still something to try.

[belst]

#0  __GI_exit (status=1) at exit.c:104
#1  0x54dc571c in std::process::exit::h01b3bf5319975c6d ()
#2  0x54afdadc in rustup_init::proxy_mode::main::h5b15f1480f4357c3 ()
#3  0x54b278bc in rustup_init::main::he9ea588d309e0baa ()
#4  0x54dd474c in __rust_maybe_catch_panic ()
#5  0x54dcebd8 in std::rt::lang_start::hb072ea7464d45b94 ()
#6  0x76e09294 in __libc_start_main (main=0x7efff434, argc=1995628544, argv=0x76e09294 <__libc_start_main+276>, 
    init=<optimized out>, fini=0x54df9615 <__libc_csu_fini>, rtld_fini=0x76fdf408 <_dl_fini>, 
    stack_end=0x7efff434) at libc-start.c:287
#7  0x54aed04e in _start ()

[nagisa]

A-ha! So its the rustup’s wrapper which is doing the early exit. (cc @brson)

@belst could you try invoking rustc directly? It should be somewhere in ~/.multirust/toolchains/{something}/bin/rustc

[ghost]

For what it's worth the same nightly works on a model 3. Both models use the same armv7 img, and only differ in hardware.

edit:
only meant to point out the hardware difference, not make an uneducated guess.

[ghost]

[pi@raspberrypi ~]$ gdb --args .multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/rustc main.rs
GNU gdb (Raspbian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".

Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from .multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/rustc...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/rustc main.rs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x731ff260 (LWP 872)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x731ff260 (LWP 872)]
0x769d7bb4 in rustc_trans::mir::constant::MirConstContext::new::he4e1ab069b9c99ae ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
(gdb) bt
#0  0x769d7bb4 in rustc_trans::mir::constant::MirConstContext::new::he4e1ab069b9c99ae ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#1  0x769df0d0 in rustc_trans::mir::constant::_$LT$impl$u20$rustc_trans..mir..MirContext$LT$$u27$bcx$C$$u20$$u27$tcx$GT$$GT$::trans_constant::hd8197320dad23619 ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#2  0x769e1164 in rustc_trans::mir::operand::_$LT$impl$u20$rustc_trans..mir..MirContext$LT$$u27$bcx$C$$u20$$u27$tcx$GT$$GT$::trans_operand::h422464b4e23f1932 ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#3  0x769e3e50 in rustc_trans::mir::rvalue::_$LT$impl$u20$rustc_trans..mir..MirContext$LT$$u27$bcx$C$$u20$$u27$tcx$GT$$GT$::trans_rvalue_operand::h732e4a147649da60 ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#4  0x769d0cbc in rustc_trans::mir::block::_$LT$impl$u20$rustc_trans..mir..MirContext$LT$$u27$bcx$C$$u20$$u27$tcx$GT$$GT$::trans_block::hc88a54279f657f65 ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#5  0x769cebdc in rustc_trans::mir::trans_mir::h543a14de51581634 ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#6  0x769761e0 in rustc_trans::base::trans_closure::h9f2aad00e64599b1 ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#7  0x769eed08 in rustc_trans::trans_item::TransItem::define::h76471544c9971e4f ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#8  0x769793c0 in rustc_trans::base::trans_crate::h75a5a0a51f75dfcc ()
   from /home/pi/.multirust/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/../lib/../lib/librustc_trans-8be786fe9ad50a77.so
#9  0x00000000 in ?? ()
(gdb) 

[nagisa]

Now, the trace strongly points to this being the same issue as all other ARM SIGILL issues. You could try to check the disassembly at the point where signal is raised to check what the instruction it is and whether it is related to neon or other optional features of ARM.

[MagaTailor]

@nagisa We're talking about an Rpi2 here, so no unsupported ARMv7 instructions SIGILL's are possible.

This is probably the first time #34427 has been triggered outside of bootstrap. @yrnameer Can you confirm the broken STR instruction? (or run with -Zorbit=off which should also work.)

[ghost]

(gdb) disassemble 0x769d7bb4,+1
Dump of assembler code from 0x769d7bb4 to 0x769d7bb5:
=> 0x769d7bb4 <_ZN11rustc_trans3mir8constant15MirConstContext3new17he4e1ab069b9c99aeE+380>:  str     r0, [r0, r11]!
End of assembler dump.
(gdb) 

The nightly I downloaded in order to test this had no orbit option.

[MagaTailor]

Right, old-trans has just been removed so you're out of luck until LLVM provide a patch.

[brson]

rustup also has a crash bug on armv7: rust-lang/rustup#687. Might be related.

[MagaTailor]

@eddyb We need some advocacy in your nicely isolated upstream issue; in the meantime ARM builds need reverting to old trans during bootstrap. Otherwise this issue is a duplicate of #34427

[eddyb]

Closing in favor of #34427.