[LLVM] Segmentation fault on MacOS with > 1 codegen units and optimization > 0

[sppalkia]

I'm seeing a segmentation fault in the Weld project during compilation when compiling with cargo build --release. This is only happening on MacOS (tested on High Sierra and Mojave); it works fine on Ubuntu 16.04. This issue also does not occur without --release.

I haven't been able to make a smaller example for this, but it seems to have started after we renamed the llvm2 submodule to llvm (weld-project/weld#440).

After some investigation, we found that any one of the following changes fix the segmentation fault, but are non-ideal:

• Add opt-level = 0 to profile.release in the Cargo manifest.
• Add codegen-units = 1 to profile.release in the Cargo manifest.
• Rename the weld::codegen::llvm to something else (e.g., weld::codegen::llvm2): this is what seems to have introduced the issue.

This is almost certainly related to #53912, but the code example in that issue seems fixed: I'll update this issue with a minimal example when I can come up with one.

The faulting command is:

rustc --edition=2018 --crate-name weld weld/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=597bae5b2ab31e15 -C extra-filename=-597bae5b2ab31e15 --out-dir /Users/shoumikpalkar/work/weld/target/release/deps -L dependency=/Users/shoumikpalkar/work/weld/target/release/deps --extern chrono=/Users/shoumikpalkar/work/weld/target/release/deps/libchrono-f261edcedff7fdf9.rlib --extern env_logger=/Users/shoumikpalkar/work/weld/target/release/deps/libenv_logger-48ad719d69c29b83.rlib --extern fnv=/Users/shoumikpalkar/work/weld/target/release/deps/libfnv-c5377afc6353fb2e.rlib --extern lazy_static=/Users/shoumikpalkar/work/weld/target/release/deps/liblazy_static-7ef694354b396823.rlib --extern libc=/Users/shoumikpalkar/work/weld/target/release/deps/liblibc-841557f1e9c82484.rlib --extern llvm_sys=/Users/shoumikpalkar/work/weld/target/release/deps/libllvm_sys-b77778a82d9c4c52.rlib --extern log=/Users/shoumikpalkar/work/weld/target/release/deps/liblog-ac2f0859500275e8.rlib --extern num_integer=/Users/shoumikpalkar/work/weld/target/release/deps/libnum_integer-9a9190e54f393ad7.rlib --extern regex=/Users/shoumikpalkar/work/weld/target/release/deps/libregex-c35e629b59596f2c.rlib --extern time=/Users/shoumikpalkar/work/weld/target/release/deps/libtime-6604aa2275081d44.rlib --extern uuid=/Users/shoumikpalkar/work/weld/target/release/deps/libuuid-7f660aa24d3f6e4a.rlib -C link-args=-Wl,-export_dynamic -L native=/Users/shoumikpalkar/work/weld/target/release/build/weld-c91c7a8f561133ca/out -l z -l c++ -l dylib=stdc++ -l static=llvmext -L native=/Users/shoumikpalkar/work/weld/target/release/build/llvm-sys-681bcfd36d11b4f1/out -L 'native=/usr/local/Cellar/llvm@6/6.0.1_1/lib'```

And LLDB gives the following information:

* thread #4, stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffff41)
    frame #0: 0x0000000106a7575d librustc_codegen_llvm-llvm.dylib`std::__1::__function::__func<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2, std::__1::allocator<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2>, bool (llvm::GlobalValue const&)>::operator()(llvm::GlobalValue const&) + 765
librustc_codegen_llvm-llvm.dylib`std::__1::__function::__func<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2, std::__1::allocator<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2>, bool (llvm::GlobalValue const&)>::operator():
->  0x106a7575d <+765>: movzbl 0xc(%rax), %eax
    0x106a75761 <+769>: andl   $0xf, %eax
    0x106a75764 <+772>: addl   $-0x7, %eax
    0x106a75767 <+775>: cmpl   $0x1, %eax
Target 0: (rustc) stopped.

[jonas-schievink]

This is very likely to effectively be a duplicate of #53912, but would be good to confirm (and hopefully fix!).

[pnkfelix]

heh. Can/should we special case llvm in our mangling algorithm to side-step this?

(are issues like this perhaps an argument for a non-bijective mangling system, to reduce the chance of painting ourselves into corners here? we really can't plan ahead for all possible lack-of-expressiveness bugs on LLVM's part, though)

cc rust-lang/rfcs#2603 and #60705

[pnkfelix]

triage: P-high to resolve our short-term response. Leaving I-nominated in hopes that we discuss at triage today.

[pnkfelix]

discussed at T-compiler meeting. Got rough approval from @michaelwoerister to put in a lint or something to detect offensive symbols as a short-term hack. The right long-term solution will come with the implementation of rust-lang/rfcs#2603 (see e.g. PR #57967 )

[davidtwco]

@rustbot claim

Assigning to self to implement lint.

[eddyb]

I'm not sure we should throw a lint at this.
We can replace the m in llvm with $6d$, and eixsting demanglers should be able to cope with it.
(We should've done this the first time, but because it was affecting rustc at that point, it would've caused further delays)