CrWinClangLLD fails the compile step |
||||||
Issue descriptionExample build: https://ci.chromium.org/buildbot/chromium.clang/CrWinClangLLD/545 It's been red for a while.
,
May 7 2018
Hopefully more readable stack: llvm::StringRef::StringRef() + 0x58 bytes(s), c:\src\llvm\include\llvm\adt\stringref.h, line 86 + 0x35 byte(s) llvm::object::ArchiveMemberHeader::getName() + 0x646 bytes(s), c:\src\llvm\lib\object\archive.cpp, line 183 + 0x15 byte(s) llvm::object::Archive::Child::getName() + 0xDA bytes(s), c:\src\llvm\lib\object\archive.cpp, line 498 llvm::object::Archive::Child::getFullName() + 0xE7 bytes(s), c:\src\llvm\lib\object\archive.cpp, line 419 lld::coff::LinkerDriver::enqueueArchiveMember() + 0x1CE bytes(s), c:\src\llvm\tools\lld\coff\driver.cpp, line 220 + 0x82 byte(s) lld::coff::ArchiveFile::addMember() + 0x16F bytes(s), c:\src\llvm\tools\lld\coff\inputfiles.cpp, line 84 lld::coff::SymbolTable::addLazy() + 0x135 bytes(s), c:\src\llvm\tools\lld\coff\symboltable.cpp, line 252 lld::coff::ArchiveFile::parse() + 0x1A7 bytes(s), c:\src\llvm\tools\lld\coff\inputfiles.cpp, line 70 + 0x36 byte(s) lld::coff::SymbolTable::addFile() + 0xA9 bytes(s), c:\src\llvm\tools\lld\coff\symboltable.cpp, line 37 lld::coff::LinkerDriver::addBuffer() + 0x393 bytes(s), c:\src\llvm\tools\lld\coff\driver.cpp, line 149 <lambda_dbbdeeaaec39dd270664c84e87261a42>::operator()() + 0x164 bytes(s), c:\src\llvm\tools\lld\coff\driver.cpp, line 183 std::_Invoker_functor::_Call<<lambda_dbbdeeaaec39dd270664c84e87261a42> & __ptr64>() + 0x30 bytes(s), c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.12.25827\include\type_traits, line 16707566 + 0x30 byte(s) std::invoke<<lambda_dbbdeeaaec39dd270664c84e87261a42> & __ptr64>() + 0x30 bytes(s), c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.12.25827\include\type_traits, line 16707566 + 0x30 byte(s) std::_Invoker_ret<void,1>::_Call<<lambda_dbbdeeaaec39dd270664c84e87261a42> & __ptr64>() + 0x30 bytes(s), c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.12.25827\include\type_traits, line 15732480 std::_Func_impl_no_alloc<<lambda_dbbdeeaaec39dd270664c84e87261a42>,void>::_Do_call() + 0x2F bytes(s), c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.12.25827\include\functional, line 15732480 std::_Func_class<void>::operator()() + 0x53 bytes(s), c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.12.25827\include\functional, line 15732480 lld::coff::LinkerDriver::run() + 0x93 bytes(s), c:\src\llvm\tools\lld\coff\driver.cpp, line 775 lld::coff::LinkerDriver::link() + 0x37C0 bytes(s), c:\src\llvm\tools\lld\coff\driver.cpp, line 1229 lld::coff::link() + 0x1A0 bytes(s), c:\src\llvm\tools\lld\coff\driver.cpp, line 75 main() + 0x2E0 bytes(s), c:\src\llvm\tools\lld\tools\lld\lld.cpp, line 124 + 0x76 byte(s) invoke_main() + 0x34 bytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl, line 79 __scrt_common_main_seh() + 0x127 bytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl, line 283 + 0x5 byte(s) __scrt_common_main() + 0xE bytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl, line 326 mainCRTStartup() + 0x9 bytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_main.cpp, line 17 BaseThreadInitThunk() + 0x14 bytes(s) RtlUserThreadStart() + 0x21 bytes(s)
,
May 7 2018
It seems to be due to the change below. ------------------------------------------------------------------------ r330786 | inglorion | 2018-04-25 01:16:39 +0200 (Wed, 25 Apr 2018) | 17 lines [COFF] create MemoryBuffers without requiring NUL terminators Summary: In a number of places in the COFF linker, we were calling MemoryBuffer::getFile() with default parameters. This causes LLVM to NUL-terminate the buffers, which can prevent them from being memory mapped. Since we operate on binary and do not use NUL as an indicator of the end of the file content, this change causes us to not require the NUL terminator anymore. Reviewers: ruiu, pcc Reviewed By: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45909 ------------------------------------------------------------------------
,
May 7 2018
If I'm holding it right, it seems to be crashing on obj/sql/test_support.lib Uploading that here for convenience.
,
May 7 2018
It's a thin archive, which is I guess why we're parsing it as a GNU file. I didn't know we used GNU-style thin archives on Windows though.. and also I suppose even then there's something wrong with the file?
,
May 7 2018
ar doesn't like it either: $ ar -t ~/Downloads/test_support.lib ar: /usr/local/google/home/hwennborg/Downloads/test_support.lib: Malformed archive Where did this come from anyway? ninja -d keeprsp -v obj\sql\test_support.lib [1/1] c:/src/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x86 False ../../../../../../src/llvm/build.release/bin/lld-link.exe /lib /llvmlibthin /nologo /ignore:4221 /OUT:obj/sql/test_support.lib @obj/sql/test_support.lib.rsp Oh, that's a thing. Okay, llvm-ar can list the contents: $ /work/llvm/build.release/bin/llvm-ar -t ~/Downloads/test_support.lib /usr/local/google/home/hwennborg/Downloads/test_support/error_callback_support.obj /usr/local/google/home/hwennborg/Downloads/test_support/scoped_error_expecter.obj /usr/local/google/home/hwennborg/Downloads/test_support/test_helpers.obj Looking at the part of test_support.lib with the string table: 000052f0: 2020 2020 600a 7465 7374 5f73 7570 706f `.test_suppo 00005300: 7274 2f65 7272 6f72 5f63 616c 6c62 6163 rt/error_callbac 00005310: 6b5f 7375 7070 6f72 742e 6f62 6a2f 0a74 k_support.obj/.t 00005320: 6573 745f 7375 7070 6f72 742f 7363 6f70 est_support/scop 00005330: 6564 5f65 7272 6f72 5f65 7870 6563 7465 ed_error_expecte 00005340: 722e 6f62 6a2f 0a74 6573 745f 7375 7070 r.obj/.test_supp 00005350: 6f72 742f 7465 7374 5f68 656c 7065 7273 ort/test_helpers 00005360: 2e6f 626a 2f0a 2f30 2020 2020 2020 2020 .obj/./0 It seems the filenames are terminated with a '/' (as the code in ArchiveMemberHeader::getName() expects), but with no null-terminator after. Should there be one? Or should the parser not be expecting one?
,
May 7 2018
GNU ar seems to put a \n after each filename (after the slash), but no null terminator. So it's not really a string table in the usual object file sense. The code should probably be changed to just look for the slash directly and not assume there's a null terminator. This should make it a little faster too :-)
,
May 7 2018
Hmm, but filenames can contain slashes, so how did looking for the slash as a terminator ever work in the first place? Anyway, fix idea here: https://reviews.llvm.org/D46527 And now I have to run.
,
May 8 2018
I tried to fix this in https://reviews.llvm.org/D46214, but ran out of time before going on vacation. I've been unable to reproduce today. I also didn't see a fix land. I'll stamp your diff so you can land that if needed. pcc requested a test case on my diff, but I haven't been able to cook one up because I'm not seeing the problem anymore. FYI the problem is exposed by my https://reviews.llvm.org/D45909 (as you identified), because that stops us from synthesizing NUL terminators after the file contents, which was previously causing StringRef(char*).find(...) to stop at EOF. The fix is to make sure we stop at EOF even if there isn't a NUL byte. My understanding is that there should still be a slash after the last file name in the long file name table, which we strip by creating a StringRef that runs until one byte before the '\n' or EOF. We don't actually look for the slash, though.
,
May 8 2018
LLVM bug tracking this is https://bugs.llvm.org/show_bug.cgi?id=37244
,
May 8 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by h...@chromium.org
, May 7 2018Status: Started (was: Available)