lld confuses object files with the same name, but from different archive files in lto mode

[llvmbot]

Bugzilla Link	30665
Resolution	FIXED
Resolved on	Oct 12, 2016 15:23
Version	unspecified
OS	Linux
Attachments	the reproducer
Reporter	LLVM Bugzilla Contributor
CC	@joker-eph,@pcc

Extended Description

Consider the following program (the full reproducer is attached):

main.cc uses symbols from two other files: one/timezone.cc and two/timezone.cc (the "timezone" is irrelevant; the meaningful part is that the name are the same, though that paths and contents are different).

The object files are linked through archives: libone.a and libtwo.a:

clang++ -o one/timezone.o -c one/timezone.cc -flto=thin llvm-ar rcsD libone.a one/timezone.o clang++ -o two/timezone.o -c two/timezone.cc -flto=thin llvm-ar rcsD libtwo.a two/timezone.o

clang++ -c main.cc -flto=thin clang++ -o main main.o libone.a libtwo.a -flto=thin -fuse-ld=lld

On top of that, it's ThinLTO, and full (not thin) archives.

This fails with:

$ ./build.sh
undefined symbol: base::CountryCodeForCurrentTimezone() clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)

Gold links correctly (so, it's not an LTO bug per se) Full LTO (-flto) instead of -flto=thin links correctly Regular (non-lto) build works correctly Thin archives (rcsDT) work correctly.

So, it's a combination of lld + ThinLTO + regular archives + the object name collision.

[llvmbot]

I have tried to compile Chrome with r284034. While I still see some issues, they seem to be unrelated to the one reported here. It's safe to say that the bug is fixed.

Thank you very much!

[llvmbot]

Ivan, p[ease try r284034. Thanks!

[pcc]

"" here is the byte offset within the archive file.

[llvmbot]

FWIW, gold (the plugin) seems to pass to thinLTO a MemoryBufferRef identified by: "llvm..." to avoid the collision.

[llvmbot]

diff --git a/ELF/InputFiles.cpp b/ELF/InputFiles.cpp index e3266f1..661e200 100644 --- a/ELF/InputFiles.cpp +++ b/ELF/InputFiles.cpp @@ -713,7 +713,16 @@ static Symbol createBitcodeSymbol(const DenseSet<const Comdat > &KeptComdats,

template void BitcodeFile::parse(DenseSet &ComdatGroups) {

• Obj = check(lto::InputFile::create(MB));
• // Here we pass a new MemoryBufferRef which is identified by ArchiveName +
• // member name + size of the archive. ThinLTO internally uses the memory buffer
• // ref identifier to access its internal data structures and if two archives
• // define two members with the same name, this causes a collision which results
• // in only one of the objects taken in consideration at LTO time (which very likely
• // causes undefined symbols later in the link).
• Obj = check(lto::InputFile::create(MemoryBufferRef(MB.getBuffer(), Saver.save(ArchiveName +
• MB.getBufferIdentifier() +
• utostr(MB.getBuffer().size()))))); DenseSet<const Comdat *> KeptComdats; for (const auto &P : Obj->getComdatSymbolTable()) { StringRef N = Saver.save(P.first());