[llvm-bugs] [Bug 37422] New: lld + ThinLTO + fprofile-generate causes duplicate symbol errors

via llvm-bugs llvm-bugs at lists.llvm.org
Fri May 11 12:17:33 PDT 2018


https://bugs.llvm.org/show_bug.cgi?id=37422

            Bug ID: 37422
           Summary: lld + ThinLTO + fprofile-generate causes duplicate
                    symbol errors
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: lto
          Assignee: unassignedbugs at nondot.org
          Reporter: pirama at google.com
                CC: llvm-bugs at lists.llvm.org

Filing issue reported in llvm-dev thread
http://lists.llvm.org/pipermail/llvm-dev/2018-May/123131.html.


The duplicate symbol errors are for __llvm_profile_filename and
__llvm_profile_raw_version.  IIUC, these are supposed to be weak symbols but
Thin LTO seems to break this in some way.  This does't happen with gold or no
LTO or full LTO.

$ cat > a.c
extern int foo();

int main() {
  return foo();
}

$ cat > b.c
int foo() {
  return 0;
}

$ clang a.c -fprofile-generate -flto=thin -c
$ clang b.c -fprofile-generate -flto=thin -c
$ clang a.o b.o -fprofile-generate -flto=thin -fuse-ld=lld
ld.lld: error: duplicate symbol: __llvm_profile_filename
>>> defined at a.c
>>>            lto.tmp:(__llvm_profile_filename)
>>> defined at b.c
>>>            lto.tmp:(.rodata.__llvm_profile_filename+0x0)

ld.lld: error: duplicate symbol: __llvm_profile_raw_version
>>> defined at a.c
>>>            lto.tmp:(__llvm_profile_raw_version)
>>> defined at b.c
>>>            lto.tmp:(.rodata.__llvm_profile_raw_version+0x0)
clang-7: error: linker command failed with exit code 1 (use -v to see
invocation)

Teresa Johnson>> From adding save-temps, it looks like lld and gold are giving
different resolutions to the symbols, which is presumably creating this issue:

Peter Collingbourne>> The problem is that ThinLTO is not dropping the
non-prevailing definitions, and they end up being emitted into the object file
for b.o.

$ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof
$__llvm_profile_raw_version = comdat any
$__llvm_profile_filename = comdat any
@__llvm_profile_raw_version = constant i64 72057594037927940, comdat
@__llvm_profile_filename = constant [19 x i8] c"default_%m.profraw\00", comdat

lld ignores comdats in LTO object files because it expects all comdats to have
already been resolved. So we see this error. 

We are supposed to drop non-prevailing symbols here, but for some reason we do
it only for weak symbols. That's not correct in ELF where comdat symbols can be
both strong and non-prevailing.
http://llvm-cs.pcc.me.uk/lib/LTO/LTO.cpp#290

This patch fixes the reproducer but it leads to other test failures that would
need to be looked at.

diff --git a/llvm/lib/LTO/LTO.cpp b/llvm/lib/LTO/LTO.cpp
index 7e8b9b3c6390..ee11d07d6b8e 100644
--- a/llvm/lib/LTO/LTO.cpp
+++ b/llvm/lib/LTO/LTO.cpp
@@ -287,7 +287,7 @@ static void thinLTOResolveWeakForLinkerGUID(
         recordNewLinkage) {
   for (auto &S : GVSummaryList) {
     GlobalValue::LinkageTypes OriginalLinkage = S->linkage();
-    if (!GlobalValue::isWeakForLinker(OriginalLinkage))
+    if (GlobalValue::isLocalLinkage(OriginalLinkage))
       continue;
     // We need to emit only one of these. The prevailing module will keep it,
     // but turned into a weak, while the others will drop it when possible.
diff --git a/llvm/lib/Transforms/IPO/FunctionImport.cpp
b/llvm/lib/Transforms/IPO/FunctionImport.cpp
index 246d75caefa2..61790c9fc435 100644
--- a/llvm/lib/Transforms/IPO/FunctionImport.cpp
+++ b/llvm/lib/Transforms/IPO/FunctionImport.cpp
@@ -765,7 +765,7 @@ void llvm::thinLTOResolveWeakForLinkerModule(
       return;
     }

-    if (!GlobalValue::isWeakForLinker(GV.getLinkage()))
+    if (GlobalValue::isLocalLinkage(GV.getLinkage()))
       return;
     // Check for a non-prevailing def that has interposable linkage
     // (e.g. non-odr weak or linkonce). In that case we can't simply

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180511/84362a0e/attachment.html>


More information about the llvm-bugs mailing list