Change:
(allowing specifying code models was to rustc in ) I want to build a large code model binary. But (correct me if I'm wrong) I believe this requires all code to be generated with a large code model (otherwise we could end up with rip relative addressing in the stdlib, which defeats the point). So I tried the obvious (controlling it with ) and got the following build log: Brief explanation of the three parts: command is run tail end of the stage1 stdlib and rustc itself being built by stage0 tail end of the stage1 stdlib and rustc itself being copied out of the stage0 build directory and into the stage1 directory, then the new stage1 rustc attempting to build the first part of the stage2 stdlib (libcore) segfaulting In fact, this stage1 rustc segfaults when not doing much: Reducing the command line used to build rustc: GDB gives the backtrace as I've dumped a bunch of info in the hope that someone might be able to lend a hand, but I can find little discussion of this feature (code models) so they may not be well-tested? I plan to investigate myself, but wanted a) to see if anyone has any pointers and b) make this a searchable issue. As a datapoint, note that redox uses a .json target specification and with , which obviously works fine. Altering the configure+make command I used to use the kernel model rather than large also worked fine. So it looks like the issue is with memory model large.
Compiling statically (with glibc, as described at ) makes it not segfault, which is interesting. Doing --enable-debug in configure also makes it not segfault. I starting to suspect the issue is in llvm (I don't think anything in the rust compiler itself generates asm?) and rust tickles the bug somehow.
Recompiling just the libstd crate without optimisations makes it work. It appears that start , which attempts to calls . calls on linux. By inspection of the parameters passed to in the linux implementation of with gdb, the parameter is an invalid pointer (checked by inspecting by ). In theory should be in steps 2 and 3, though the functions look like they've all been inlined.
Managed to tear down std to get this test case: (it seems that since I originally reported this issue, the nightlies now have llvm assertions enabled)
Abort seems to be coming from TwoAddressInstructionPass. Backtrace (from gdb) at the point of abort is: <details<summaryClick to expand backtrace</summary<p</p</details
The rust code two comments up () when compiled with will produce . Inspecting with llvm-dis: If you now try and compile this with you will hit the assertion (assuming your llvm has assertions enabled): It works fine on the latest LLVM head. Turns out the fix was merged december 7th - is the bug, is the fix.
Looking at the llvm 4 release branch on the llvm-mirror github, this will be fixed when rust upgrades -
I backported the referenced patch, built a debug rust with it (i.e. debug-rust-large-fixed) and then built a release mode rust also with the backported patch and debug-rust-large-fixed (which took forever) and successfully ended up with a release-rust-large-fixed which can build itself.
Presumably fixed by LLVM backport -- doesn't reproduce today. I'm marking as E-needstest since it seems like something we should track in tests.
fwiw this is tricky to do a test for unless we want to do yet another rustc build in CI. I'm going to be rebasing our Rust fork 'shortly' and was planning to just close this issue once that's done and I've verified everything is working.
Oh... do we need to rebuild rustc for it? I was under the impression that just was enough to test. That's all I did...
Urgh yes. Sorry, this issue has a lot of history for me and I'd forgotten parts of it. Running the testcase above is indeed a valid test of the issue :)
Triage: apparently a test, but it was removed before it was merged.

Discussion:
<ins> // only-x86_64 // compile-flags: -Ccode-model=large --crate-type lib // build-pass // // Regression test for issue #37508 #![no_main] #![no_std] #![feature(thread_local, lang_items)] #[lang = "eh_personality"] extern "C" fn eh_personality() {} use core::panic::PanicInfo; #[panic_handler] fn panic(_panic: &PanicInfo<'_>) -> ! { loop {} } pub struct BB; #[thread_local] static mut KEY: Key = Key { inner: BB, dtor_running: false }; pub unsafe fn set() -> Option<&'static BB> { if KEY.dtor_running { return None; } Some(&KEY.inner) } pub struct Key { inner: BB, dtor_running: bool, } </ins>