rustc/LLVM DiagnosticKind mismatch causes crash when bootstrapping unoptimized w/ MIR.

[canndrew]

I'm unable to build rustc with MIR on my machine. I've tried to do a completely fresh build by running:

$ git clone https://github.com/rust-lang/rust
$ cd rust
$ ./configure --enable-debug --disable-docs --enable-orbit
$ make check-stage1

.. and rustc segfaults

rustc: x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore
/home/shum/src/rust/rust/mk/target.mk:212: recipe for target 'x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.core' failed
make: *** [x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.core] Segmentation fault

I'm running gentoo linux-3.14.14 x86_64 on a Core i7-2677M with 4GB of RAM.

[MagaTailor]

Probably the same as #34427

[eddyb]

@petevine But isn't #34427 ARM-specific?

@canndrew Do you have a backtrace?

[canndrew]

@eddyb You're darned tootin' right I do! But it's not a very good one...

Thread 2 (Thread 0x7fffea5c8700 (LWP 29952)):
#0  0x0000000000000001 in ?? ()
#1  0x0000000000000008 in ?? ()
#2  0x00007fffea5b5328 in ?? ()
#3  0x00007fffea5b5328 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7fb1a00 (LWP 29947)):
#0  0x00007fffebbfe7dd in pthread_join (threadid=140737125320448, thread_return=0x0) at pthread_join.c:90
#1  0x00007ffff713a353 in std::sys::thread::{{impl}}::join (self=...) at /home/shum/src/rust/rust/src/libstd/sys/unix/thread.rs:152
#2  0x00007ffff772dd96 in std::thread::{{impl}}::join<()> (self=0x7fffffffcf30) at /home/shum/src/rust/rust/src/libstd/thread/mod.rs:627
#3  0x00007ffff772dcee in std::thread::{{impl}}::join<()> (self=...) at /home/shum/src/rust/rust/src/libstd/thread/mod.rs:687
#4  0x00007ffff7726cdc in rustc_driver::monitor<closure> (f=...) at /home/shum/src/rust/rust/src/librustc_driver/lib.rs:1050
#5  0x00007ffff76febcb in rustc_driver::run (args=...) at /home/shum/src/rust/rust/src/librustc_driver/lib.rs:136
#6  0x00007ffff778d8c8 in rustc_driver::main () at /home/shum/src/rust/rust/src/librustc_driver/lib.rs:1115
#7  0x000055555555493b in driver::main () at /home/shum/src/rust/rust/src/driver/driver.rs:21
#8  0x00007ffff713d5b6 in fn$LP$$RP$::fn_pointer_shim.32324::h35d87cadf14a8183 () at /home/shum/src/rust/rust/src/libcore/option.rs:323
#9  0x00007ffff713d2f3 in std::panicking::try::{{closure}}::{{closure}}<(),fn()> () at /home/shum/src/rust/rust/src/libstd/panicking.rs:250
#10 0x00007ffff713d5fd in std::panicking::try::call<closure> (f=0x7fffffffdb20) at /home/shum/src/rust/rust/src/libstd/panicking.rs:282
#11 0x00007ffff7167858 in __rust_try () from /home/shum/src/rust/rust/x86_64-unknown-linux-gnu/stage1/lib/libstd-f53fb285.so
#12 0x00007ffff71677a8 in panic_unwind::__rust_maybe_catch_panic (f=0x7ffff713d5e0 <std::panicking::try::call<closure>>, data=0x7fffffffdb20 "\340\334\377\377\377\177", data_ptr=0x7fffffffdb08, 
    vtable_ptr=0x7fffffffdb00) at /home/shum/src/rust/rust/src/libpanic_unwind/lib.rs:91
#13 0x00007ffff713d21b in std::panicking::try::{{closure}}<(),fn()> (s=0x7ffff7fb19e0) at /home/shum/src/rust/rust/src/libstd/panicking.rs:257
#14 0x00007ffff713d796 in std::thread::local::{{impl}}::with<core::cell::Cell<usize>,closure,core::result::Result<(), Box<Any>>> (
    self=0x7ffff74e9598 <std::panicking::PANIC_COUNT::h99b79c8949805cd2>, f=...) at /home/shum/src/rust/rust/src/libstd/thread/local.rs:245
#15 0x00007ffff713d11c in std::panicking::try<(),fn()> (f=0x555555554930 <driver::main>) at /home/shum/src/rust/rust/src/libstd/panicking.rs:245
#16 0x00007ffff713d06b in std::panic::catch_unwind<fn(),()> (f=0x555555554930 <driver::main>) at /home/shum/src/rust/rust/src/libstd/panic.rs:312
#17 0x00007ffff713cf69 in std::rt::lang_start (main=0x555555554930 <driver::main> "UH\211\345", <incomplete sequence \353>, argc=24, argv=0x7fffffffdf78)
    at /home/shum/src/rust/rust/src/libstd/rt.rs:58
#18 0x000055555555497a in main ()

I have no idea what's going on over in thread 2 there.

[canndrew]

This happens on my other machine aswell 😦
Also running Gentoo, linux-4.0.5 x86_64, Core 2 Q9400 with 4GB RAM.

[MagaTailor]

@eddyb Could be but a MIR-only memory error would have been too big a coincidence to ignore.

[eddyb]

@petevine Well, we did find the Rust cause for #34427 and ARM codegen turns it into a problematic instruction. Regardless, the key element here is --enable-debug with no optimizations, which is not officially supported.

[MagaTailor]

I'm sure you're right, however the Rust cause is clearly related to MIR, and LLVM codegen could well be fine. (that's my bet for now)

[eddyb]

@petevine The Rust cause of #34427 is the implementation of MIR, coupled with LLVM ARM codegen.
This bug, however, depends on --enable-debug. x64 linux is known to build with MIR without --enable-debug whereas last I heard, --enable-debug didn't actually bootstrap, regardless of MIR.

[canndrew]

@eddyb Correct. --enable-debug was breaking it. Should I open another issue about that?

[eddyb]

With a debug LLVM (on the upgrade to 3.9 branch) I get this:

inlinable function call in a function with debug info must have a !dbg location
  call void @_ZN4core9panicking5panic17h585bd70cda921012E({ %str_slice, %str_slice, i32 }* @panic_loc12745)
LLVM ERROR: Broken function found, compilation aborted!

This only happened with -Z orbit, so it is MIR-specific.

[eddyb]

@canndrew I can't reproduce on current master, only on the LLVM upgrade branch (fix for that is #35141).

[canndrew]

@eddyb Well it was broken for me on yesterday's master, from a fresh clone 😕

[sanxiyn]

I can reproduce on master, 535cea0, --enable-orbit --enable-debug, make rustc-stage2. Segmentation fault in the same place.

[eddyb]

@sanxiyn Can you reproduce by running ./x86_64-unknown-linux-gnu/stage1/bin/rustc -Z orbit -g src/libcore/lib.rs manually? Can you get a backtrace?

[sanxiyn]

Yes, I can reproduce manually. Backtrace is similar to what @canndrew already posted.

#0  0x0000000000000001 in ?? ()
#1  0x0000000000000008 in ?? ()
#2  0x00007fffea983378 in ?? ()
#3  0x00007fffea983378 in ?? ()
#4  0xffffffffffffffff in ?? ()
#5  0xffffffffffffffff in ?? ()
#6  0x0000000000000000 in ?? ()

[eddyb]

@sanxiyn Can you dump info registers and info proc mappings? This might be a stack overflow, which would explain the mangled backtrace.

[eddyb]

On IRC @sanxiyn has provided enough information to track it down to DiagnosticKind, which we wrap on the Rust side even though it's an unstable C++ enum. They got out of sync. Our LLVMGetDiagInfoKind should translate between the C++ enum and a Rust-specific one.

There should be no C++ types in the rustllvm C API

This is very important, for both compatibility with more than one version, and for keeping our Rust definitions working across LLVM upgrades without silent breakage (like this one).
#34743 fixed one instance (RelocationModel), but there's probably more lurking around.

cc @alexcrichton @badboy @rust-lang/compiler

[eddyb]

@sanxiyn managed to get it to print:

note: optimization analysis for inline at [unknown]: _ZN4drop17hbeeee56e4a9dc3c4E should never be inlined (cost=never)

I have no reason to believe this is MIR-specific, just triggered by MIR due to a combination of factors.

diagnostic_handler has a default arm and @sanxiyn and I are speculating that, given optimizations, it would likely catch the UB of llvm::diagnostic::Diagnostic::unpack (the value is 8, the Rust enum goes up to 7).