[Bug gold/22868] New: Gold does not select proper symbol visibility when used with LLVM gold-plugin

[georgerim at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22868

            Bug ID: 22868
           Summary: Gold does not select proper symbol visibility when
                    used with LLVM gold-plugin
           Product: binutils
           Version: 2.31 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at gmail dot com
          Reporter: georgerim at gmail dot com
                CC: ian at airs dot com
  Target Milestone: ---

Issue is following. If we have 2 IR files, where the same
weak symbol has different visibility:

comdat.ll:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define weak_odr i32 @f1(i8*) {
  ret i32 42
}

comdat_input.ll:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define weak_odr protected i32 @f1(i8* %this) {
  ret i32 41
}

Then symbol expected to be protected in output.
Invocation used:
llvm-as comdat.ll -o comdat.ll.tmp1.o
llvm-as comdat_input.ll -o comdat.ll.tmp2.o
./ld.gold -shared -o out.gold -plugin <path>/LLVMgold.so comdat.ll.tmp1.o
comdat.ll.tmp2.o -m elf_x86_64

But at fact now symbol is not protected:
readelf -a out.gold
...
  Symbol {
    Name: f1 (44)
    Value: 0x290
    Size: 6
    Binding: Weak (0x2)
    Type: Function (0x2)
    Other: 0
    Section: .text (0x5)
  }

And if I switch order of objects to comdat.ll.tmp2.o comdat.ll.tmp1.o then it
becomes protected:

  Symbol {
    Name: f1 (44)
    Value: 0x290
    Size: 6
    Binding: Weak (0x2)
    Type: Function (0x2)
    Other [ (0x3)
      STV_PROTECTED (0x3)
    ]
    Section: .text (0x5)
  }

It is broken starting from following commit:
http://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5dc824ed42cd173c1525f5abc76f4091f11a4dbc

Before commit above symbol always was STV_PROTECTED as expected.

This was reported for LLVM initially here:
https://bugs.llvm.org/show_bug.cgi?id=36166

-- 
You are receiving this mail because:
You are on the CC list for the bug.