rustc broken on sparc64

[karcherm]

During a rust build on sparc64, the following crash is observed:

shell$ /usr/local/bin/rustc --crate-name libc src/vendor/libc/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on --cfg feature=\"default\" --cfg feature=\"use_std\" -C metadata=aa5c1e1a6631cab2 -C extra-filename=-aa5c1e1a6631cab2 --out-dir /root/rustc-1.21.0+dfsg1/build/bootstrap/debug/deps -L dependency=/root/rustc-1.21.0+dfsg1 /build/bootstrap/debug/deps --cap-lints allow -C link-args=-Wl,-z,relro -Zremap-path-prefix-from=/root/rustc-1.21.0+dfsg1 -Zremap-path-prefix-to=/usr/src/rustc-1.21.0
Bus error

This is a side effect of #44646 which runs into #39696. Many (if not all) constructors of syntax::ext::tt::quoted::TokenTree create a Span member (which is now repr(packed)) inside the discriminated union. The discriminator is a single byte, so the Span member is laid out at offset 1 (and followed by 3 padding bytes, so packing didn't gain us anything). The automatically derived PartialEq instance for TokenTree crashes when comparing e.g. two Token objects, because after the tag comparison (0 in both cases), it performs unaligned loads on the Span values resulting in a bus error.

[glaubitz]

CC'ing @bgermann @binarycrusader @jakllsch @japaric @jrtc27

[infinity0]

Would adding #[cfg(not(target_arch = "sparc64"))] to the relevant #[repr(packed)] annotation(s) be a likely temporary workaround? I don't have access to sparc machines so can't test this myself.

[infinity0]

If the #[cfg] applies to the whole struct definition (i.e. what I suggested would delete the definition on sparc64), it might be necessary to duplicate it just without the #[repr(packed)] annotation.

(Of course the proper fix is to fix the underlying issue of unaligned access being generated in the first place, but a temporary fix would allow sparc64 to be bootstrapped today.)

[glaubitz]

Would adding #[cfg(not(target_arch = "sparc64"))] to the relevant #[repr(packed)] annotation(s) be a likely temporary workaround? I don't have access to sparc machines so can't test this myself.

I'm testing such a change now.

[glaubitz]

Ok, this works. See the PR above.

I'm not sure whether this is the best way to write the conditional compiling, but it works.

I'm open for suggestions on improving this, of course :).

[MartinHusemann]

This sounds like a bad hack. For one, the repr(packed) should just be ignored in this case (where cpu alignment forces the same layout), and second (as noted above) there is no excuse to generate bogus code for this case.

[glaubitz]

This sounds like a bad hack. For one, the repr(packed) should just be ignored in this case (where cpu alignment forces the same layout), and second (as noted above) there is no excuse to generate bogus code for this case.

It's a workaround which is necessary as #39696 hasn't been resolved yet and is apparently not easy to fix.

Feel free to suggest a better solution.

[glaubitz]

So, with a current rustc snapshot from git, this particular issue with rustc throwing a SIGBUS is gone and when including the patch by @jrtc27 to fix the stack alignment on SPARC (rust-lang/llvm#94), I can cross-build a Rust compiler for sparc64-unknown-linux-gnu which no longer crashes.

However, using that cross-compiled rustc for sparc64 apparently produces broken binaries:

root@stadler:~# cat hello.rs 
fn main() {
    // The statements here will be executed when the compiled binary is called

    // Print text to the console
    println!("Hello World!");
}

root@stadler:~# rustc hello.rs
root@stadler:~# ./hello 
Bus error
root@stadler:~# gdb ./hello
GNU gdb (Debian 7.12-6+b1) 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 ./hello...(no debugging symbols found)...done.
(gdb) r
Starting program: /root/hello 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x0000010000006064 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::h4ca565533725b233 ()
(gdb) bt
#0  0x0000010000006064 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::h4ca565533725b233 ()
#1  0x0000010000007390 in std::rt::lang_start::he07d85b827d35475 ()
#2  0x00000100000050e0 in main ()
(gdb)

[glaubitz]

Ok, with the latest git snapshot, the compiler now works fine for me on sparc64-linux-gnu.

So, I think it's safe to close this issue now.

[sanxiyn]

Closing as requested.

[glaubitz]

@sanxiyn I think #39646 can be closed in this context as well.