<div dir="ltr">Hi Sylvestre,<div><br></div><div>isn't this another instance of the clang-7/gcc ABI issue around Optional?</div><div><br></div><div>llvm::DIBuilder::createFile accepts Optional arguments, and more than once people complained to me or on IRC about that particular call segfaulting.<br></div><div><br></div><div>Cheers,</div><div>Philip</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018 at 9:54 AM Sylvestre Ledru via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Lately, I have been working on moving Debian & Ubuntu packages to a<br>
stage2 build.<br>
<br>
This means that, instead of shipping llvm-toolchain packages built with<br>
gcc, we are rebuilding<br>
everything a second time using the newly built clang.<br>
<br>
Now, when pushed to Debian, it caused some unexpected issues in<br>
particular with rust reported here:<br>
<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913271#35" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913271#35</a><br>
<br>
rustc in Debian was building initially against libllvm built with gcc.<br>
It was working fine.<br>
The failure is now happening when the systems saw their libllvm upgraded<br>
to the stage2 bootstrap one.<br>
<br>
The beginning of the backtrace is the following (generating debug info):<br>
<br>
Thread 1 "rustc" received signal SIGSEGV, Segmentation fault.<br>
0x00007ffff1e273bc in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1<br>
(gdb) bt<br>
#0  0x00007ffff1e273bc in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1<br>
#1  0x00007ffff1f654c9 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1<br>
#2  0x00007ffff1f65491 in llvm::MDString::get(llvm::LLVMContext&, llvm::StringRef) () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1<br>
#3  0x00007ffff1ee69cd in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1<br>
#4  0x00007ffff1ee2d12 in llvm::DIBuilder::createFile(llvm::StringRef, llvm::StringRef, llvm::Optional<llvm::DIFile::ChecksumInfo<llvm::StringRef> >, llvm::Optional<llvm::StringRef>) () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1<br>
#5  0x00007ffff50a01f2 in LLVMRustDIBuilderCreateFile (Builder=0x5555555d4180, Filename=0x7ffffffeedd8 "src/<a href="http://main.rs" rel="noreferrer" target="_blank">main.rs</a>", Directory=0x555555b3dd10 "$HOME/hello_world")<br>
    at /usr/lib/llvm-7/include/llvm/ADT/StringRef.h:85<br>
#6  0x00007ffff501d39e in rustc_codegen_llvm::debuginfo::metadata::compile_unit_metadata (tcx=..., codegen_unit_name=..., debug_context=0x7ffffffeeeb0) at librustc_codegen_llvm/debuginfo/<a href="http://metadata.rs:859" rel="noreferrer" target="_blank">metadata.rs:859</a><br>
<br>
Disabling the debug generation for rustc fixes the issue (thanks to Ximin Luo for the investigation).<br>
<br>
Why idea how to workaround this issue ?<br>
<br>
Unfortunately, because rustc needs rustc to build itself, I cannot check if a simple recompilation fixes it or not.<br>
<br>
Cheers,<br>
S<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>