[llvm-dev] lld/lto/win32 crash on DIE code

[Carlo Kok via llvm-dev]

Ah damn yes. I have a modified llvm to support my custom personality. I'll try and prepare one with standard personalities Monday.

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180316/30587022/attachment.html>