chrome_elf.dll fails to link with LTO using LLD |
|||
Issue description
I think something like this is happening:
The entry point is __DllMainCRTStartup@12
That's defined in libcmt.lib(dllcrt0.obj), and it refers to _DllMain@12
In SymbolTable::createLTOObjects() we say addMustPreserveSymbol("_DllMain@12"), but because the function is called "DllMain" in the bitcode file chrome_elf_main.obj, it gets dropped.
,
Oct 12 2016
Hmm, in BitcodeFile::parse(), the symbol is named _DllMainCRTStartup@12. Is this some kind of name scheme mismatch between linker names and the names used in LTOCodeGenerator::preserveDiscardableGVs()?
,
Oct 12 2016
Yes, we were failing to include the stack byte count in the mangled name used by LTOCodeGenerator::preserveDiscardableGVs(). I've sent out https://reviews.llvm.org/D25529 which fixes your test case.
,
Oct 12 2016
The fix landed in r284040.
,
Oct 13 2016
Thanks! chrome_elf.dll links now. I got confused by how the symbol could be resolved to the bitcode file even though it didn't match the name of the function in the IR. Do I understand correctly that bitcode files have a symbol table that uses the *mangled* names? I tried to figure this out in BitcodeWriter but failed. If you happen to know how this works, could you point me in the right direction?
,
Oct 13 2016
(meant to mark it fixed, not started) |
|||
►
Sign in to add a comment |
|||
Comment 1 by h...@chromium.org
, Oct 12 2016Repro: D:\src\llvm\build.release64>type d:\src\tmp\a.cc #include <windows.h> BOOL APIENTRY DllMain(HMODULE module, DWORD reason, LPVOID reserved) { return TRUE; } D:\src\llvm\build.release64>bin\clang-cl -m32 -flto -fuse-ld=lld /dll d:\src\tmp\a.cc