<html><head></head><body>Ah damn yes. I have a modified llvm to support my custom personality. I'll try and prepare one with standard personalities Monday.<br><br><div class="gmail_quote">On March 16, 2018 8:16:41 PM GMT+01:00, Evgeny Leviant <eleviant@accesssoftek.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hello Carlo,<br><br>I tried your reproducer and faced different problem from one you described<br>(I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens<br>when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function:<br><br>ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext<br><br>This happens because LLVM doesn't know your personality function (@_elements_exception_handler), so I suggest looking<br>at llvm::classifyEHPersonality function as well.<br><br><hr><br>От: llvm-dev <llvm-dev-bounces@lists.llvm.org> от имени Carlo Kok via llvm-dev <llvm-dev@lists.llvm.org><br>Отправлено: 14 марта 2018 г. 15:42<br>Кому: llvm-dev<br>Тема: [llvm-dev] lld/lto/win32 crash on DIE code<br><br>I have a fairly recent LLD/LTO llvm crashing on<br><br>DIE *ContextDIE = getOrCreateContextDIE(Context)<br>being null for a (local) variable. (Context is a DICompileUnit in this<br>case, but it's not present in MDNodeToDieMap so it returns null.<br>callstack is:<br><br>llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode)<br>Line 718 C++<br>llvm::DwarfUnit::addType(llvm::DIE & Entity, const llvm::DIType * Ty,<br>llvm::dwarf::Attribute Attribute) Line 768 C++<br>llvm::DwarfCompileUnit::applyVariableAttributes(const llvm::DbgVariable<br>& Var, llvm::DIE & VariableDie) Line 897 C++<br>llvm::DwarfCompileUnit::finishVariableDefinition(const llvm::DbgVariable<br>& Var) Line 725 C++<br>llvm::DwarfDebug::finishVariableDefinitions() Line 655 C++<br>llvm::DwarfDebug::finalizeModuleInfo() Line 677 C++<br>llvm::DwarfDebug::endModule() Line 768 C++<br>llvm::AsmPrinter::doFinalization(llvm::Module & M) Line 1348 C++<br>llvm::FPPassManager::doFinalization(llvm::Module & M) Line 1559 C++<br>`anonymous namespace'::MPPassManager::runOnModule(llvm::Module & M) Line<br>1615 C++<br>llvm::legacy::PassManagerImpl::run(llvm::Module & M) Line 1700 C++<br>llvm::legacy::PassManager::run(llvm::Module & M) Line 1732 C++<br>compileModule(char * * argv, llvm::LLVMContext & Context) Line 572 C++<br><br>The input of this testcase is huge, full repro.tar is here: (14mb)<br><a href="https://www.dropbox.com/s/ugv9sfqouhlszff/repro.tar?dl=0">https://www.dropbox.com/s/ugv9sfqouhlszff/repro.tar?dl=0</a><br><br>With lld /lldsavetemps I managed to narrow down what it actually fails<br>on, specifcally from the Island.Tests.Windows.exe.0.5.precodegen.bc<br>(which fails too when passed to llc -O1)<br><br>This is the pattern that it generates:<br><a href="https://gist.github.com/carlokok/fb0f1bf213ee4599d8f2442e37b23f03">https://gist.github.com/carlokok/fb0f1bf213ee4599d8f2442e37b23f03</a><br><br>If I read this correctly it somehow ends up using two compile units at<br>once from the same type and failing because of that. I don't know if<br>that's a merging bug or something I'm doing, but none of my input bc<br>files has more than 1 compileunit per file, so I don't know how this<br>could have happened.<br><br>What can I do to solve this?<br><br><br>Thanks,<br><br>carlo Kok<br><hr><br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>