thread 'rustc' has overflowed its stack on sparc64-unknown-linux-gnu

[glaubitz]

With the two changes from #45456, I am able to cross-build rustc and cargo.

While cargo works fine on sparc64-unknown-linux-gnu, rustc crashes with a stack-overflow:

root@deb4g:~# uname -a
Linux deb4g 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017-10-15) sparc64 GNU/Linux
root@deb4g:~# rustc hello.rs 

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
Aborted
root@deb4g:~#

CC'ing @binarycrusader @jakllsch @japaric @jrtc27 who might be able to give some hints.

[glaubitz]

Here's what gdb says:

root@deb4g:~# gdb /usr/local/bin/rustc
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 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 "sparc64-linux-gnu".
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 /usr/local/bin/rustc...(no debugging symbols found)...done.
(gdb) r /root/hello.rs                                                                                                                                                      
Starting program: /usr/local/bin/rustc /root/hello.rs                                                                                                                       
[Thread debugging using libthread_db enabled]                                                                                                                               
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
[New Thread 0xfff80001097bd910 (LWP 115392)]

Thread 2 "rustc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xfff80001097bd910 (LWP 115392)]
0xfff80001076ae2b8 in __ctzdi2 () from /usr/local/bin/../lib/../lib/../lib/librustc_llvm-2cab755ba8bcc047.so
(gdb) bt
#0  0xfff80001076ae2b8 in __ctzdi2 () from /usr/local/bin/../lib/../lib/../lib/librustc_llvm-2cab755ba8bcc047.so
#1  0xfff80001076ae2e8 in __ctzdi2 () from /usr/local/bin/../lib/../lib/../lib/librustc_llvm-2cab755ba8bcc047.so
(gdb) quit
A debugging session is active.

        Inferior 1 [process 115389] will be killed.

Quit anyway? (y or n) y
root@deb4g:~#

[japaric]

ctzdi2 is a compiler builtin that comes from the compiler-rt project. The "stack overflow" message could indicate that the implementation has an infinite recursion bug or similar. Could you check that the following Rust program doesn't crash when executed on a SPARC machine?

fn main() {
    extern "C" {
        // C signature: int __ctzdi2(long x)
        fn __ctzdi2(x: i64) -> i32;
    }

    // you may need to test different inputs to trigger the bug (if there's one)
    println!("{}", unsafe { __ctzdi2(0) });
}

(N.B. CTZ stands for Count Trailing Zeros)

[glaubitz]

@japaric It crashes the same way as rustc:

root@deb4g:~# ./bugtest 

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted
root@deb4g:~#

and the backtrace seems to indicate an infinite recursion as well:

root@deb4g:~# gdb ./bugtest 
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 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 "sparc64-linux-gnu".
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 ./bugtest...done.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /root/bugtest.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) r
Starting program: /root/bugtest 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000001000002a4fc in __ctzdi2 ()
(gdb) bt
#0  0x000001000002a4fc in __ctzdi2 ()
#1  0x000001000002a52c in __ctzdi2 ()                                                                                                                                       
Backtrace stopped: previous frame inner to this frame (corrupt stack?)                                                                                                      
(gdb)

[glaubitz]

Oh, very interesting, I just found this https://github.com/rust-lang/compiler-rt/pull/27/files:

#if (defined(__sparc64__) || defined(__mips_n64) || defined(__mips_o64) || defined(__riscv__) \
+		|| (_MIPS_SIM == _ABI64) || (_MIPS_SIM == _ABIO64))
+si_int __clzsi2(si_int);
+si_int __ctzsi2(si_int);
+#define	__builtin_clz __clzsi2
+#define	__builtin_ctz __ctzsi2
+#endif /* sparc64 || mips_n64 || mips_o64 || riscv */

This is veeeeery suspicious because there is definitely a workaround for this particular issue on sparc64.

However, on sparc64-linux-gnu, the compiler does not define __sparc64__. Instead, it defines __sparc__ && __arch64__. I will try to change that and if it fixes it, I will replace __sparc64__ with __sparc__ && __arch64__ which is defined on both BSD and Linux.

[glaubitz]

However, on sparc64-linux-gnu, the compiler does not define sparc64. Instead, it defines sparc && arch64. I will try to change that and if it fixes it, I will replace sparc64 with sparc && arch64 which is defined on both BSD and Linux.

Yes, this fixes this particular issue:

root@deb4g:~# ./bugtest 
64
root@deb4g:~#

[binarycrusader]

Yes, exactly, see https://github.com/rust-lang/compiler-rt/pull/31/files

[glaubitz]

@binarycrusader Yep. My suggestion would be to use __sparc__ && __arch64__ as this is defined on Linux, BSD and Solaris.

[glaubitz]

After fixing this issue, we ran into this: #45509

[glaubitz]

As rust-lang/compiler-rt#33 got just merged, I'm closing this.